Pause Button

Hi everyone. I've decided to put this blog on-hold for a period of time to concentrate on other projects - there are only so many hours in the day after all! My Management Blog will still continue as before and is likely to include the odd post on management in Agile environments.


Thanks, Gary.

Is Planning Poker Effective?

This may seem like an odd question to ask given the general industry popularity and success of Planning Poker, but I think it's worth a closer look. 

Planning Poker is a form of estimation technique known as Wideband Delphi, the basic principle being that you gather as a group to collectively understand and then estimate either a single or multiple user stories - most likely using a series of numbered cards. I won't go into any more detail than that, because if you're reading this blog the chances are that you're already familiar with the process. If not, check out the Wikipedia entry for further information.

So why do I have a problem with Planning Poker? The short answer is that I don't (we use it at my current organization), but there are a number of factors to consider when looking at whether it's the correct estimation tool for you today:

• Single Points of Failure. The idea behind Planning Poker is that a group of individuals estimating a task will produce a more accurate estimate than a single individual doing the estimate. Implied in this is an assumption that you're not estimating for a user story that requires specialist knowledge and there's only a single individual in your organization with that knowledge. If you only have one specialist then you have other problems - and I'd suggest these need to be resolved first. It's hard to estimate as a group when the majority are not clear on what would be involved in the implementation.
• Organizational buy-in. Agile adoption usually begins within the Software Development Department and then scales out to the rest of the organization. In the interim, other departments within the organization will often take the view that Planning Poker is a massive waste of time. 5 to 10 people in room for an hour or more just to estimate a story or three - what a waste! People who've used Planning Poker know that isn't the case, but the success of Agile relies partly on perceptions of how efficient it is.
• People get hung up on the difference between a '5' and an '8' and Planning Poker sessions drag on as a result. This is wasteful and people can often become disillusioned with the process as a result. You're after a reasonably accurate estimate and over time your team will build up a body of knowledge and eventually move towards more relative sizing of stories. If it's either a 5 or an 8 go with the majority, or go with the safest option. Go with something.
• Tendency to come up with solutions. Get a number of developers in a room and they naturally want to start to build solutions. A mindset shift and time are both required to get the team to a point where they're going into just enough detail to be able to accurately estimate without going through the entire design process.
• Geographical location. Planning Poker involving physical cards can be tricky if your team are not co-located. Fortunately this is a problem that can be overcome using technology. Check out PlanningPoker.com for further information. Even with electronic tools, however, co-location is still beneficial. Maybe you can get the team together once a month for a planning session?

So does Planning Poker work? - of course it does. But I think it's worth being aware of the conditions required to make it a success.

The Importance of a Social Platform

The Agile Manifesto expresses a preference for "Individuals and interactions over processes and tools". And while technology and technology-based tools are important (it's quite difficult to develop software without them), I fully support this statement. Without those interactions it's incredibly hard to elicit requirements and almost impossible to determine whether what you're developing is in line with what's required. Involvement of, and close working with, the customer is one of the major tenets of developing software in an iterative fashion after all.

There is, however, another element related to individuals and interactions which is often over-looked during the adoption or use of an Agile framework - the social interactions between members of the development team. In the traditional sense of the word, one wouldn't necessarily place the word 'social' and 'developer' in the same sentence - at least not in the stereotypical, Dilbert-esque world. But developers are, in my opinion, highly social.

Look, for example, at an organization that is currently using a waterfall methodology to develop software, i.e. an environment where interactions are not necessarily encouraged. You'll still find individual teams running discussion forums and Wikis, or using IM clients as a means of communicating regularly and disseminating information. The message is clear - social interaction is important in the development of software no matter whether it's encouraged by the organization or not.

Move this into the Agile world, an environment where these interactions are actively encouraged, and it's easy to see this social interaction expanding to cross-departmental Wikis where information is shared across the whole organization for the greater good in a central location rather than being handed-off manually from one team's Wiki to another's, or where the casual social interactions are 'formalised' so we foster behaviours such as linking change sets to Wiki entries to improve the maintainability of software. 

It's clear that social interactions are important for the development of software - and personally I would say that even amongst organizations who are 'doing Agile' more could be done to enhance this way of working.

How do you encourage social interaction within your Agile organization?

Transitioning to Agile

A while back I wrote a post on choosing an Agile framework. In the latest article over on my main site, I've expanded my thinking on this subject. I'd welcome your thoughts and comments, either in response to this post or by contacting me directly.
Alternatively, you can download the article in PDF format.

Dealing With Short-Notice Annual Leave

As you can probably tell from the title, this blog post is very specific - and also a very valid thing to consider when working in short iterations. Your team have committed to deliver a specified number of story points in the current sprint and part-way through a team member announces that they need to take a few days annual leave. How does the team deal with this?

For me, the first stop is a management assessment of the request. If someone needs to attend to a family emergency, for example, then it may be that you can't (and shouldn't) even consider denying the request for leave. Regardless of what you decide (or whether the request for annual leave is a true emergency) there are a number of other things you may wish to consider doing:

• Have a conversation. Agile ways of working promote conversations as part of the 'process', so get the entire team around the whiteboard to discuss the annual leave request. If the request is granted, can the team still deliver on their commitments? If the answer is 'yes' then maybe you don't have a problem (provided the remaining team members are still fully bought-in to delivery). If the answer is 'no' and the request for annual leave is not related to an emergency situation then team pressure can be an incredibly useful device in persuading the individual that they, along with everyone else, made a commitment that they need to deliver on, i.e. that taking the leave is not appropriate.
• Ask the individual to put in additional effort between now and the date of the leave to ensure that the team can still deliver.
• Consider de-scoping features. If the request for annual leave is urgent and simply cannot be denied, then you may have no other choice. It's as simple as that. 
  • Even where the leave is not critical, you may choose to grant the request anyway. In doing this, you need to be very careful of the message that this sends to both the other team members and the business. Is it really worth it? Personally, I would shy away from this option in a non-emergency situation.
• Agree to play it by ear. Do you need to make the decision right now, or can you see how much progress the team is making in 1 to 2 weeks time and then make the call?

Thoughts?

Agile in a Fixed-Price Environment

My organization works with some very large customers who have complex procurement processes in place with budgetary approval and purchase order sign-off needing to go through multiple departments before work can actually begin. They like to know how much a project is going to cost up-front and they expect to be billed for that exact amount.

This presents some challenges for a software house operating in an Agile manner. Think about that for a second. You want to deliver software to your customers in short iterations to gain early feedback and then push that feedback into future iterations - but this can affect the overall (fixed) cost of the project that was agreed up-front. How do you handle that situation?

For me, there are a number of possible solutions:

• Fix project price, but flex on project scope. Go ahead and draw a financial line in the sand, deliver in small iterations and get the feedback you need. If the feedback you receive affects project scope to the point where you can't or don't want to absorb the cost internally then go back to the customer and discuss which areas you can sacrifice that are of lower priority in order to make the changes received through the feedback. This can work, but clearly you're going to need customer buy-in up front. This may prove unpalatable to customers who have a feature list that comprises solely of 'must haves'. 
• Use Agile internally and present a waterfall exterior to the customer. This can work (to some extent). You can develop release quality, working software each iteration...you just don't release it. Obviously you don't get the early feedback, which is a major drawback, but I still think it's better than running a 6-month project only to find at the end of the 5th month that you're not going to deliver, or can only 'deliver with caveats'.
• Fix project price and scope, but include contingency for re-work following iteration feedback. Many large organizations are used to working with a contingency pot for mid-project change requests. Include this 'pot of money' in the initial estimate with the expectation on both sides that it will be used.
• Fix project price and scope and be prepared to absorb all additional costs internally. This doesn't sound cost-effective (and it probably isn't) but you might choose to do this if you believe that developing in an Agile manner will yield other commercial benefits either for this or subsequent projects.

Thoughts?

Thoughts On Collective Code Ownership

Agile (at least in part) is about forming small, cohesive, well-motivated teams where each team possesses all the skills they need in order to get the job done. During a sprint, some developers' timescales may slip, while others' will get ahead. To ensure that the sprint is delivered on time, you need a team that contains multiple generalists, i.e people who can work on multiple areas of the code so the team as a whole stand a reasonable chance of delivering even when problems are hit. To anyone familiar with Agile practices, this is not news.

For me, enabling this involves a few things, including:

• Eliminating single points of failure within the team, i.e. avoiding the situation where the skills required to complete a particular task lie with a single team member.
• Making the code as easy to work with as possible, i.e. so anyone can pick it up and make changes. 

So how do you achieve this? I've found that the following works well:

• Get non-experts working on features. Estimate for any team member doing the work (not just the expert) and allow time for non-experts to pair program alongside experts as required. This will help eliminate single points of failure and increase the number of generalists on your team.
• Enforce coding guidelines / standards, so that code is formatted in the same way across the codebase. This makes it easier to read and work with. Code will be familiar to each team member, and they're more likely to feel a sense of ownership. 
• Run team building exercises that encourage collective code ownership such as Coding Dojos. This will help improve the efficiency of pair-programming on your commercial products and will also improve team cohesiveness. 

Collective code ownership isn't necessarily without it's problems though... 

• You could argue that a generalist is more likely to break code in any one particular area. You can't know everything in-depth across the entire code base, so aren't you just likely to introduce additional risk? This is where Test Driven Development comes in. If you have a comprehensive suite of unit tests, a non-specialist can make a change and have confidence they haven't broken anything else.
• If more people are changing any one area of the code base, direct coding conflicts (conflicting change sets) are more likely to occur. This is where Continuous Integration can help. If conflicts are raised as soon as code is checked in, the overhead / impact of resolving them is much smaller.
• It requires developers set their egos aside. People who were responsible for the initial creation of a particular module are often reluctant to let it go and be modified by other developers. Good documentation (formal or code commenting), knowledge sharing and developer briefings can ensure that future code changes are made in line with the original design.

As a final note, I'm not saying that a team shouldn't contain specialists and that you, as a Team Lead, shouldn't take advantage of their skills in a particular area. But just bear in mind that having knowledge reside with a single person is a dangerous business and as the Team Lead it's your responsibility to mitigate that risk.