Scrum – All the gear, no idea?

I have a problem with Scrum – although the problem isn’t really the Scrum methodology itself, but rather some of the people who (attempt) to adopt it.

I’d liken it to Harley Davidson motorcycles or perhaps Gibson guitars – both great products, especially if they’re acquired by people who know what they’re buying and how to use them. Unfortunately, what tends to happen is that they’re also purchased by people from the outside – usually in their first foray into the sector, without any understanding of what they actually need to make full use of their purchase. For a motorcycle, where and how you ride should normally be an important factor in the type of motorcycle you purchase. Likewise, things like target musical genres and any preferred style of play will dictate what type of guitar you will want to buy (if you regularly play songs in different tunings, you may regret having that Floyd Rose tremolo on your guitar). There are obviously a huge number of other factors to consider, but I’ll avoid digressing further for now. My point is, if you don’t completely understand what you need, you’re likely to go in the wrong direction.

Going with the flow?

So, how does that relate to Scrum? Well, when you’re looking at changing the way you work, you’ll probably have a number of things to consider: what size are your teams and how many do you have, how complex are the products you’re developing, what constraints are you working with (budget, time, organisational structure) and so on. In life, there are very few solutions where one size truly fits all – but a great many tend to make this assumption with Agile – especially in relation to Scrum. More often than not – Scrum is adopted without any form of analysis about what it provides and where it fits. Ask people to list just three pros and cons about what they’ve chosen and many will struggle. Ask them why they went with Scrum and they’ll often tell you that it’s the most popular – so it must be great, right?

Now, the vast majority of people who bought their new Harley or an awesome Gibson SG will find themselves very happy with what they’ve got – but not all… While a bad purchase may have some resale value, chances are that making a bad decision about your approach to delivering software will not see a good a return. At worst, you might have failed to deliver a viable product, drove away your best talent and spent all your money. Game over.

Measure, evaluate, adjust.

Ok, so maybe that’s extreme and in most cases you’ll probably do alright. However, I’d expect a good team to do more than blindly following a prescribed way of working and instead, actually look at what pain-points they have and where their greatest inefficiencies lay. You should have some understanding of where you could improve and what benefits addressing area that could bring. You can do that at any point – before you transition to Agile, after, during – or even if you never chose to adopt an Agile methodology.

Even if Scrum (or any other particular methodology) is a good fit, it’s probably not going to be perfect. If you want confidence that you’re doing the best you can, you should have some understanding of at least some alternative approaches. There’s actually a large number of agile ways of working – some sharing ideas, some diverging. If you adopt a continuous improvement mindset, you should be regularly evaluating what you do and why you do it. Don’t just follow the masses.

Now, you may be aware that Harley Davidson isn’t the worlds only motorcycle manufacturer. If they were “the best”, why do other brands still exist and why do people continue to buy them? Depending on what you measure, who “the best” is can vary quite dramatically. Scrum benefits from being relatively easy to understand and limited in scope (divorcing itself from engineering practices). That might make it a good choice for starting to learn about Agile – but does it continue to add as much value in the different stages of your journey?

A bad workman blames his tools.

One constant I’ve observed is that who you have on your team is much more crucial than the processes, tools or methodologies at hand. A team of motivated, talented people can achieve a huge amount very quickly.

For me, a good methodology provides the least amount of interference required to ensure that all the effort expended is in the right direction (and also provides a clear measure of progress). I’d assert that the level of “interference” should probably take into account the level of skills in your team, their previous track record and how well understood the project’s goals are. Done badly, Scrum can come across as micro-managing and almost condescending. It’s an old adage, but if you’ve hired good people – get out of their way! Let them demonstrate how they’d approach things given a free rein.

If you’ve got bad people, sorry but Scrum isn’t going to magically fix that. Nothing is. However, be careful who you consider to be the “bad” people. Quite often, the developers or delivery team get left with the blame for any project going awry, simply because they’re at the end of the chain. Sometimes it genuinely is poor tooling (yes, you can blame your tools) or a number of other upstream issues that really derailed the project long beforehand. It wasn’t a bad workman. As often as not, the core issue actually relates to poor planning, unclear direction or bad management decisions completely outside of their control. Too many companies shoot the messenger without realising that is what they’re doing.

Nowadays, it’s very tempting to adopt fashionable trends – especially when they promise so much (transformation to an efficient, ultra productive nirvana). Scrum is one of many tools at your disposal, just try to ensure you have a clear understanding about the problems that it’s potentially going to solve for you. Agile is very much in vogue at the moment – use it wisely, don’t just be someone with “all the gear”…

Are all developers equal?

In Scrum, only 3 roles are prescribed; Product Owner, Scrum Master and Developer (Team Member). It suggests that we let go of our traditional roles (and job titles) to form an embedded team, that collaborates and cross-skills.

“All developers are equal, but some developers are more equal than others”

I have spoken to several project and delivery managers who struggle to envisage this approach working in the real world. Their opinion is typically that contrary to Scrum’s idealistic vision, in practice they need to be able to map specialisations (and therefore, roles) into a project team to ensure that the relevant skills and experience are present to set it up for success.

They assert that the hard reality is that not everyone is a “superstar” that is able to generalise (certainly to the standard required) and that Scrum doesn’t work in its purest (or purist) form with team members of varying levels of ability. For example, a dedicated tester may be adept at test-automation, whereas a junior C# developer may lack this experience. Your project will vary in quality and speed of delivery depending on the composition of the team.

Discussion

I’d be interested to hear how people have addressed (the perception of) this issue and how they try to ensure each of their Scrum teams has the right mix of skills to guarantee success?

Please share your thoughts and experience by posting your comments below. 🙂

Responsibility inversion

Responsibility inversion is an extremely common management anti-pattern, present in many organisations. It occurs when a person in a more senior role (in terms of hierarchy or experience) does not delegate sufficient responsibility to those more junior than themselves, even though they possess the relevant skills, ability or experience.

With the following diagram in mind, consider a typical career progression progression path, with a manager and their report(s) as an example:

Responsibility inversion principle

In the Venn diagrams above, the upper circles represent the more senior role, their skills and experience and the lower circles represent the more junior role. The intersections represent the overlap in skills and experience.

The Responsibility Inversion Principle asserts that if you prevent someone from using their abilities they will begin to lose them (shown on the left). Whereas, when they are allowed to exercise their ability, under the guidance of someone senior, they’ll actually grow their ability.

One common example of an inverted responsibility situation you may encounter is the much lambasted “ivory tower architect“. Instead of focusing on higher-level concerns outside the logical scope of the senior developer role, they’ll spend time dictating all but the lowest-level aspects of their skill set. They do not trust or empower developers to make use of their experience – removing the opportunity for them to create or influence solutions, designs or to make any related decisions about the software they will be expected to deliver – instead they’ll be spoon fed the results of the architect’s own (isolated) activity.

If you’ve employed talented people, this inversion will be a massive source of frustration which will slowly erode their skills (through lack of use), quality of work and output if left unchecked. The more astute will leave to pursue opportunities elsewhere long before it comes to that…

Talent retention aside (although you’ll be aware how big an issue that can be), the inverted approach doesn’t scale! Taking on as much as possible and delegating as little as possible creates a huge bottleneck that isn’t always very obvious from outside the team. Time that should be invested in important areas is rushed to continue to feed work to their reports (compounding the frustration of those who could have done a better job, given the chance).

There are many potential reasons for this situation. It can emerge from a perceived lack of skills in the more junior employees – or from a lack of trust. It can also come from a desire of the senior person to (continue to) be seen as valuable or irreplaceable to the business – or simply as a result of unconscious actions (in ignorance of what they’re doing). Whatever the root cause, the result can be toxic in the long term.

Regardless of the role within an organisation, you will usually find that there is a substantial amount of overlap in the overall skills and experience required to carry out the related day-to-day responsibilities, yet many organisational structures place people in silos – as if the entirety of those skill sets are mutually exclusive. Whilst this loses some economy of scale in larger structures, some delineation is required for effective coordination of activity – “somebody’s gotta be the ensign“.

Some career paths have evolved to avoid this pitfall fairly naturally – such as the route from junior to lead software developer. One might expect to begin their career as a support developer then progress in to a senior developer role and (eventually) beyond – leading teams or perhaps moving into architecture. In a healthy organisation, there’s usually an implicit requirement in their senior development roles to support and mentor more junior developers. They’ll be coached and assigned progressively larger and more difficult pieces of work. All the work they produce is reviewed by the senior, who will then give appropriate and constructive feedback to the junior – demonstrating areas that they can improve. Over time they will grow to fill the shoes of their mentor.

It’s important to note that using the delegation approach in no way diminishes the more senior role. The skills you learn by communicating your experience, explaining complex concepts and being able to divide and distribute large undertakings of work help set you up for your next challenge.

So how does this relate to Agile software development or scaled Agile? An Agile self-governing team not only promotes the vertical progression described above, but can also provide a great way for people to expand their skills horizontally – from the additional experience gained in embedded team roles, rather than being limited by a traditional silo position. You’ll find that people naturally gravitate to areas where they have the aptitude and interest. When people are given the opportunity to grow like this, you may be pleasantly surprised how much your team starts to achieve.

Are Agile certifications worth it?

I recently came across this article on InfoWorld talking about “7 agile certifications to take your career to the next level”. I read it hoping to gain some insight on their opinion of how certification would benefit your career. Did they think the value came from the skills you learn from obtaining the certification or are there certain “Agile” qualifications sought after by employers?

Of course, I already have an opinion on the value of Agile certifications from my own experience – and I have to admit a large bias in that area. Now, whilst I’d actively encourage anyone to attend some of the various training courses and coaching sessions on offer to actively learn as much as they can (in addition to their own self-learning), I don’t personally place much value in Agile certifications. Most can be obtained after a short (in some cases, single day) course with a relatively easy exam at the end (many with near-guaranteed pass rates).

I find they’re usually required by companies that aren’t very agile and typically demonstrate a Dunning-Kruger failure to recognise genuine ability in others (and their own lack of knowledge) relating to Agile methodologies, practices and associated ways of working. This is usually evident from the questions they’ll ask you about your Agile experience. Instead of questions like:

• What are the biggest problems you’ve encountered using Agile methodologies – how would you try to tackle them?
• What was your role within the team and what other roles were included in the scope of your team’s work?
• How many teams were working on the same product – how did you work together successfully?
• What other methodologies do you have experience of – how do they compare?

You’ll probably just be asked:

Are you a “Certified ScrumMaster”?

It may (or may not) surprise you that this simple question is all too often the first (and only) question asked to assess my Agile credentials…

To me, most Agile certifications are purely a money making scheme for the companies that offer them – and are absolutely no guarantee of ability. The fact that a (very) high percentage of them require you to renew your qualification every 2-3 years – without any additional training or assessment – speaks volumes. Take them for what they are. If you can gain a qualification after just a few days training and with no practical application of those newly gained skills, great – just don’t place any more value on that piece of paper than you would for anyone else with a similar level of experience…

The role of an Agile architect

“Architecture is about the important stuff. Whatever that is.”

That’s what Martin Fowler told us way back in 2003. If you’re interested in the field of software architecture, it’s probably a quote you’re already familiar with. It’s often repeated, but it doesn’t really help explain what architecture is – or why it’s important. If we continue reading the same article, Fowler goes on to highlight a quote that goes a little further, from Ralph Johnson:

“Architecture is the decisions that you wish you could get right early in a project, but that you are not necessarily more likely to get them right than any other.”

Software development would be oh-so-easy if there was a reliable way to create a completely fit for purpose and efficient design up-front. Agile emerged partly from a realisation that our understanding of what we need will always change over the course of our development efforts. That could just mean adding more detail to our understanding or changing it substantially – that’s why we actively strive to respond to change in the way we work.

Even if we’re in an unlikely situation where we have a complete understanding of what we want now, there is very little chance we’ll know exactly how to solve all the problems we’re going to face getting there. We could spend lots of time up-front, acknowledging that there are risks with a completely predictive approach – or we could spend very little (or no) time in up-front design, reacting to any problems as they become known. Many Agile projects choose the latter and as a result produce less than elegant solutions – and are rightly criticised for it as a result…

How much forethought is enough?

We can’t accurately predict the future, so it seems a little unwise to rely on our precision in that area. Likewise, an entirely reactive approach is probably not going to be very efficient either – especially if we’re forced to rework large areas of our solution on a regular basis. So, we’re faced with a choice about how much time (and to what level of detail) we should invest in the architecture of our solution up-front. Talking about Agile Modelling, Scott Ambler described his “just barely good enough” approach:

I like to say they are just barely good enough (JBGE). I make the following critical points about a model or document (an artifact) being just barely good enough:

• It is actually the most effective possible
• It is situational
• It does not imply low quality
• It changes over time
• It comes sooner than you think

All fairly self-explanatory, but in relation to his last point, he expands his explanation to include a very astute observation:

“Traditionalists seem to assume that significant investment in modeling, and corresponding specification, will continue to add value over time.”

This is a common assumption I’ve encountered many times myself. Funnily enough, in situations where the delivery of a project is delayed (or even derailed) by poor architectural decisions emerging after new information surfaces part-way through the delivery process, the response is often: “Go back, spend more time up-front and this time do it right!”

If the previous activity exposed the only show-stopper your design will encounter, there’s a chance you’ll now be equipped with the information required to address the problem. The problem with this attitude is that in complex systems (and many simpler ones) there’s likely to be a whole host of potential show-stoppers – many in competition with each other. So what is the answer?

My advice echoes Scott’s – do just enough. What that looks like is highly situational, it doesn’t mean you can accept low quality and it may have to change over time. The traditionalist assumption was that prolonged investment will continue to add value – it kinda does, but the return is ever diminishing. There’s a sweet-spot, where after a certain point you’re spending more time than the value you’re adding – that’s the time to stop!

The Agile architect

In the same article from Martin Fowler we cited at the start of this one, he goes on to define two types of architect. The first is described as:

The person who makes all the important decisions. The architect does this because a single mind is needed to ensure a system’s conceptual integrity, and perhaps because the architect doesn’t think that the team members are sufficiently skilled to make those decisions. Often, such decisions must be made early on so that everyone else has a plan to follow.

Fowler’s first description is often associated (though sometimes unfairly) with the traditional architect job titles, who sit above lowly developers, dictating their every move from their ivory towers. That doesn’t sound very Agile to me… In contrast, the second type is described as:

This kind of architect must be very aware of what’s going on in the project, looking out for important issues and tackling them before they become a serious problem. When I see an architect like this, the most noticeable part of the work is the intense collaboration. In the morning, the architect programs with a developer, trying to harvest some common locking code. In the afternoon, the architect participates in a requirements session, helping explain the technical consequences of some of their ideas in nontechnical terms – such as development costs.

This time, we have someone actively collaborating with the other members of their team. They have an awareness of the overall project and spend time working on high and low-level problems. They get their hands dirty when required, but are also able to communicate with anyone less technical. This person sounds like someone useful to have around – and could fit in to an Agile environment very well.

If you have someone producing a design in a silo, who does not spend time with the people who are building or requesting that change, then you have an ivory tower architect. In a nutshell, collaboration is the mark of an agile architect.

Pulling it together

• Start with a simple design, because at the beginning, you won’t have enough of a design to support all the software.
• Have a more and more robust design as the project goes on, because you can’t make progress with insufficient design.
• Wind up with a fully robust design, capable of supporting the whole project and its future needs.

Source: http://ronjeffries.com/xprog/blog/context-my-foot/

From the point you embark upon your mission to deliver the Product Owner’s vision in an Agile way, you should be collaboratively refining your understanding about what is required. You then agree on their relative priority and begin thinking about the ways to implement those ideas. Early on, your team should have some idea about what the minimum viable product (MVP) might look like. From there, you need to start articulating how you are going to start building it.

With any complex problem, there is very rarely ever just one “right way” to solve it – and those solutions aren’t going to be perfect. There’s always going to be some form of trade-off, that cannot be avoided. A good architect should have enough experience to highlight where some of these trade-offs may occur (and what the potential impact could be). Armed with that information, what you should be doing is finding a solution that could work, then quickly proving whether or not it is going to be (just barely) good enough. Importantly, that means good enough for what your product needs to do now – not what it may need to do later.

To give you a related example, I once attended a talk given by George Berkowski about his book “How to Build a Billion Dollar App”. He described how a team had spent months of long hours and late nights to get an app finished and ready for its launch. After a huge push they got it finished and it launched – then no one downloaded it! At the time, he reflected that they could have just created a single page website instead, to see if anyone ever actually clicked the download link. If as it turned out, no one did, they could have saved a huge amount of time and money. This example was originally given to illustrate the need to prove a market demand for an idea, rather than any technical design concerns, but it transcends the business lesson.

If you identify that your application component really has to handle 1000 concurrent requests from day one, that will impact the architecture of your application. Just letting your team blindly hack away without any discussion is unlikely to be effective – but don’t be tempted to try to predict every bottleneck and point of contention either.

Instead, formulate a plan to prove your proposed initial design can handle those 1000 requests in an identified test scenario. Then, continue working together with the (embedded or prescriptive) developer, test and other roles – leveraging their expertise to bring that idea to life. If one way doesn’t work, fine – move on to the next solution candidate and continue working until you’ve satisfied your minimum acceptance criteria.

Remember that meeting the business acceptance criteria doesn’t necessarily mean the solution is good enough (as the focus is very often solely at the functional level). Your team may still be faced with some refactoring required to clean the code up to a maintainable state – or you might have some edge-cases or other functionality to implement. The important thing is the team has proven a solution for the current situation.

A huge benefit of this approach is that you’ll probably learn about several pinch-points and possible limitations along the way. Often this is information you would not have predicted in advance, but you are now left in a very good position – where you are better able to explain the consequences of any change introduced later. For example, if the Product Owner subsequently wanted to add more functionality to a key user journey, where the change may affect performance, you will have detailed knowledge of many of the likely bottlenecks.This knowledge is based on empirical evidence (from your work in that area), not a crystal ball. You can help the Product Owner accurately assess whether the value added from any changes are going to be worth the cost to develop going forward. That level of understanding is a great place for any product team to get to.

Agile team communication

Encouraging good communication within a team is one of Agile’s key areas of success. From daily stand-ups to pair programming, refinement and retrospective meetings, working in an open and collaborative way is a core tenet of Agile, whichever framework or methodology you subscribe to.

No hierarchy?

Many Agile approaches attempt to instigate flat organisational structures, where everyone on a team is (theoretically) on equal terms. You’ll also encounter evangelists using somewhat counter-productive phrases, such as “no more managers” or “remove all hierarchy” or similar calls promoting the abolition of traditional reporting structures.

In reality, you’ll find that the world (and by extension, all our work) is inherently hierarchical. Even a typical Scrum team has an implicit hierarchy in the form of the Product Owner. Sure, they don’t manage the team in the traditional sense – and in more mature Agile teams, they won’t be dictating what is included in each sprint – but they do have some authority. They get to choose this feature over that, set work priorities, time-box development activity and more – they’re just not micro-managing the technical development.

Scrum of Scrums

When there is more than one team, one approach to coordinate their efforts is the Scrum of Scrums:

With this approach, each Scrum team proceeds as normal, but each team identifies one person who attends the Scrum of Scrums meeting to coordinate the work of multiple Scrum teams. These meetings are analogous to the daily Scrum meeting, but do not necessarily happen every day.

The team member from each team attending the Scrum of Scrums is generally known as the team’s “ambassador”. Interestingly, the role that attends this meeting is not fixed (it could be the Scrum Master, Product Owner or one of the technical contributors). This leaves three important issues:

1. What is the agenda and knowledge of the attendee – business and technical roles often have conflicting priorities (and an Agile coach / Scrum Master may not understand either).
2. When there is inevitably some conflict between teams (priority, dependencies, solution architecture etc.), who is ultimately responsible for making those decisions?
3. Whose responsibility is it to maintain an overall product direction for the teams? What controls are in place to ensure the Scrum of Scrums team is able to reach a (consistent) consensus?

Network approach to communication

In Setchu, instead of using the Scrum of Scrums technique, it uses a predefined two-tier hierarchy. Multiple Agile feature teams are accountable to a single control team (made up of a Product Owner and Product Architect on equal standing):

Network based communication.

Teams (and any member thereof) are strongly encouraged to communicate informally and often, in a network manner, between each other to resolve minor issues and dependencies. There’s no hierarchy between the feature teams, but they are expected to try to reach decisions both sides are comfortable with, for most day-to-day interactions. Whenever that’s not possible or when a discussion highlights a wider concern, the issue is bubbled up to their (mutual) control team:

The control team is able to offer guidance and make decisions that are in the best interests of the overall product. As this team is a split between business and technical concerns, it is able to provide balanced solutions (and assess the wider impact) to their feature teams.

In this model, each team has clear ownership of its responsibility (and authority). When there is any ambiguity, there is a well-defined, central authority present to resolve the conflict – who are also ultimately accountable for the success of the product.

We are not chickens, nor are we pigs!

I frequently see Scrum teams continuing to use “Chickens and Pigs” to describe someone’s relationship to the team. Despite the potential negative connotations, I often read new articles and documentation still using this terminology – and there doesn’t seem to be much sign of this slowing down…

Now, for some, it may surprise you to know that the origin of the “Chicken and Pig” terminology was deliberately removed from the Scrum Guide way back in 2011 – yet people continue to use it. So, what do these animal names relate to in the real world of product development?

Participants

Not pigs!

This is your Agile (product or feature / “Scrum”) team – the people who will collaboratively work towards the team’s goal. Your team may occasionally include a number specialists, consultants and subject matter experts for portions of your product’s delivery (many scaled Agile frameworks acknowledge these as “secondary roles“). If you participate, you’re a participant – simple.

Observers

Not chickens!

This is anyone your team is likely to consult or inform. They may be stakeholders, accountable for the successful delivery of your product, but they are not responsible for implementing it (in the DAD framework, it specifically uses “stakeholder” to refer to someone materially impacted by the success of the product). They could also be the PMO, finance or some other function providing wider governance beyond the team’s “what and how” responsibility. All these observers may have influence over the product development, but they aren’t (actively) participating.

Interactions

If you’re going to attend a daily stand-up, it should be to participate, not just observe. Stating “I’m a chicken!” when it’s your turn to give an update just isn’t helpful. However, always remember that Agile requires collaboration to achieve its goals – so don’t attend if you’re going to try to dictate your agenda (if you have the authority, communicate your priorities via the Product Owner instead, for them to add to the team’s backlog where appropriate).

Don’t derail the process. Let the team be responsible for the level of detail it needs to be to get things done. Trust them to do their job, while they trust you to do yours.

Clear Responsibility

If we are dismissive of any possible offence or hurt feelings from those involved (poor little Jimmy doesn’t like being labelled as a dirty, ignorant pig), then what is the problem with referring to people as chicken and pigs?

To some, it may sound unprofessional, while to others it may be Zeitgeist. Personally, I don’t like overloading common, well understood words with non-intuitive meanings (and we’re already pushing our luck with “Agile”).
Most importantly, one thing Agile is frequently accused of is obfuscating common sense. That is exactly what these terms were doing – replacing words understood outside of the software development and product management context and creating an ambiguous, industry specific usage. That’s two legs baaaad, we’re not farm animals!

Common problems adopting Agile

Agile is not a silver bullet – despite what many claim. Agile doesn’t magically improve delivery, but it can bring significant improvements if approached in the right way. Let’s take a look at how not to introduce Agile into your organisation.

Beware of Waterfall in Agile clothing

I’ve found on many occasions that when a business issues a diktat that they will now implement Agile, it can be difficult for them to make the conceptual shift. Sometimes they’ll (unintentionally) keep their existing structure and processes and simply go through a renaming exercise instead. However, as we well know:

• The Scrum Master is not a project manager
• The Scrum Team are not all developers
• The Product Owner should not be a business analyst

So, if you have simply filled new Agile roles with the nearest equivalent traditional job title, there’s a strong chance you haven’t changed much about the way you work – instead you have simply renamed your current methodology to sound more “Agile”.

You’ll also see projects become “epics”, requirements may become “stories”, meetings are suddenly “stand-ups” and planning is now called “grooming” – but has any of this your improved your output?

Evangelists cause issues

Once a decision has been made to become “Agile”, an early step embarked upon for many businesses will be to recruit an Agile specialist. There are a two important issues with this approach:

First, these specialists are often aligned to one specific methodology (we’ll discuss that later). At worst, they will apply it dogmatically, without the pragmatism required to effect change in some larger or more traditional organisations.

Second, the criteria for recruiting these specialists is often that they have a relevant Agile certification, as that is the only way they have of assessing a candidate’s Agile credentials. For any methodology to be successful, sufficient practical experience is required. This doesn’t come from books or (one-day) courses.

Don’t default to Scrum

Scrum is Agile, but Agile is not Scrum. Scrum isn’t the only Agile methodology in town (even as I often default to using Scrum terminology…), yet it’s often adopted without any consideration about what it actually provides and what limitations it may have.

Scrum may be the best-fit for your needs, but you should always perform some analysis based on the specific situation you’ll be working in. Furthermore, don’t fall into the environment / scalability trap. All too often, I’ve seen Scrum trialled isolation, with a small independent team, then it gets rolled out across a much larger organisation with several teams (and their complex dependencies) thinking that it will just work. It very often doesn’t.

Each software methodology has its pros and cons – what looks good in theory may not be as successful in the real world. Try some out.

Narrow scope limits change

The most common mistake when trying to become more Agile, is that changed practices are only applied to the technical phases (usually just build). Requirements are still gathered up front, then there is a design phase. After the now “Agile” build phase, a test and release phase follows and so on. This is a red flag that you’re actually using a sequential methodology (like Waterfall…) instead of an agile methodology.

This is a problem because you’re going to be severely limiting the potential benefits that can be realised by adopting a more Agile approach by constraining the scope of change in this way. As many businesses eventually discover, the build phase is often the least of their problems when it comes to successful project management.

Sometimes other phases are actually included in the “Agile” scope, but they will occur in an isolation fashion instead of collaboratively. The scope of a Sprint is dictated by the business and Scrum Master (in private), rather than agreed by the team.

Divorced responsibility

Another pseudo Agile anti-pattern is “pushing (problems) over the fence”. This will typically take the form of the business expecting the Agile team to deliver requirements that haven’t been articulated or even formed yet – and then not being involved in the activities designed to find them out.

Issuing requirements akin to “whatever it does now” also demonstrates a distinct lack of stakeholder engagement. The business needs to take responsibility for ensuring their team has a complete understanding of their expectations if that is what they hope to deliver. Collaboration is one of the most important aspects of Agile and can be the most difficult culture to change.

Agile with deadlines using time-boxing

In an excellent article from Mike Cohn, where he talks about budgeting when you can’t estimate, he touches on an important but often overlooked Agile practice, time-boxing:

Instead of asking a team, “How long will this take?” the business thinks, “How much time is this worth?” In effect, what this does is create a budget for the feature, rather than an estimate. Creating a budget for a feature is essentially applying the agile practice of timeboxing. The business says, “This feature is worth four iterations to us.” In a healthy, mature agile organization, the team should be given a chance to say if they think they can do a reasonable job in that amount of time. If the team does not think it can build something the business will value in the budgeted amount of time, a discussion should ensue. What if the budget were expanded by another sprint or two? Can portions of the feature be considered optional so that the mandatory features are delivered within the budget? Establishing a budget frames this type of discussion.

I’m sure there will be distant shouts of “it’s done when it’s done”, but I regard that as a negative attitude and somewhat unrealistic. Everything we produce (in a commercial context) is paid for by the business, so ultimately they should be in control of how much they spend. Whilst time-boxing doesn’t guarantee they’ll get (everything) that they want, it should ensure costs don’t spiral.

There are three critical aspects to successful time-boxing, collaboration, ante and negotiation (think CAN you time-box).

Collaboration

In order to have the best possible chance of realising the value the business hopes to achieve within the time-box, the whole team will need a clear understanding of what the ideal outcome would be. Focus should be on what is really needed and how to prioritise to get there.

Negotiation

If there is enough uncertainty or too many unknowns, it’s crucial that the requirement is negotiable. As the article mentions, can portions of the feature be considered optional? The aim should be to negotiate a modular / gradual outcome where at least the lower spectrum of value can be delivered within the constraints with relative confidence.

This is very much an application of the INVEST characteristics defined by Bill Wake:

• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

This principle is usually applied to user stories, which is what the portions of the feature provoking the time-box should be broken down into.

Ante

The ante is the size of the time-box, the monetary stake in the game. If the uncertainty is very high, the business has to accept the risk that the stake’s value may not be returned.

Occasionally, due to the size or complexity of a feature (or possibly external factors), it may become clear that the feature MVP cannot be delivered within the time box. If it’s likely to be significantly incomplete, this should become clear relatively early on. If you’re 2 Sprints into a 4 Sprint time-box and have only completed 10% of the effort for the minimum viable elements of the feature, there’s a strong chance the remaining 90% will not be completed in the remaining time.

With the above example in mind, you have three choices:

• Fold – you’ve reached a point within the time-box where it looks like you’re not going to get a return so you fold early, ending the time-box.
• Call – you hold your nerve until the end of the time-box. It’s still possible that you’ll get the output / value you want. As we all know, burn-down is non linear.
• Raise – at the end of the time-box, the team may have delivered most of the portions of the feature, but you may now feel it’s worth a small extension (based on the team’s velocity) to add more value.

In theory, you could also raise the ante if the team didn’t deliver the minimum viable feature negotiated at the start. I’d usually recommend against this as it’s difficult to assess progress if you don’t have “working” software to base your projections against. Your budget (in terms of money or time) was negotiated early on – spending more than the feature adds is precisely what this approach should avoid.

Was Bruce Lee the first Agile practitioner?

Let’s take a look at some well known quotes from the legend that is Bruce Lee:

“All fixed set patterns are incapable of adaptability or pliability. The truth is outside of all fixed patterns”

“Obey the principles without being bound by them”

That sounds like Bruce Lee was strongly in favour of responding to change. What about his approach to planning?

“If you spend too much time thinking about a thing, you’ll never get it done”

“A goal is not always meant to be reached, it often serves simply as something to aim at”

That sounds applicable to retrospectives and using empirical evidence to drive decisions. Two quotes this time about using a lean approach:

“It’s not the daily increase but daily decrease. Hack away at the unessential”

“The less effort, the faster and more powerful you will be”

Both reflect the Agile manifesto’s principle “Simplicity – the art of maximizing the amount of work not done – is essential”. Then we have:

“Man, the living creature, the creating individual, is always more important than any established style or system”

To me, this has very strong echoes of the Agile manifesto’s value “Individuals and interactions over processes and tools”.

There are many more applicable examples! I’m beginning to wonder if it’s merely a coincidence that the first papers introducing adaptive and incremental software development processes surfaced in the early 1970’s?