blogs.conchango.com

Most organisations that we see adopting Agile approaches for large programmes or across an entire organisation have already seen success with one or more Agile projects. In fact, we wouldn’t recommend not having seen a few successes before embarking on large scale adoption! Based on these early successes there is a temptation to simply “Hit the gas” and do a lot more of the same by simply multiplying the small number of successful teams. Life just isn’t that simple and very often large scale adoption runs into trouble. There are many reasons for this:

• Early Agile teams have usually chosen an Agile approach themselves as opposed to the later teams who have the decision thrust on them by a corporate mandate.
• A small number of Agile projects can be a sufficiently small target and slip under the radar so as not to fall foul of corporate project management offices or be viewed as a significant threat to the status quo.
• The vision for what the organisation is trying to achieve and why it is adopting an Agile approach is poorly communicated to all those who are going to be affected by the change.
• An underestimation of the impact on organisational functions like HR and logistics.
• Resistance from middle management who feel threatened by the concept of self organising teams.
• Resistance from staff who are either in an operational role or have some operational responsibility, like application support for example where it is more difficult to see how Agile approaches can be applied.
• Departmental structure and management hierarchy – common issues are management interference with the team’s working practices and requests to work on other work outside of the project.

Communication, communication, communication …….

Getting buy-in is vital, as is communicating the “Big picture” of what is at stake. I listened to Kent Beck speak at the Agile Business Conference and he told the story of a cleaner at NASA. When this cleaner was interviewed he responded to the question of “What do you do?” by answering “Son - I send people to the moon”. This is a man who doesn’t just clean toilets but clearly gets the big picture of what his organisation’s mission is! One of the manifestations of people not understanding the overall goal is “Sub optimisation” (see Lean Software Development - Mary & Tom Poppendieck). You see this in multi-team environments where the teams just focus on their own piece of the puzzle to the detriment of the overall programme. I’ve seen extreme cases where teams don’t even have visibility of their own requirements backlog but exist on just the small list of the next iteration’s priority features fed to them by their Product Owner. I liken this to running full tilt along a London street with your eyes firmly fixed on the ground or driving at 70mph in the fog! Without visibility of what’s ahead a team will tend to make poor design decisions. Without an overall picture of the wider programme objectives a team will see any task like integration with other team’s work as an irritation and impediment to getting their real work done.

So communication is absolutely key – I don’t think I’ve ever heard anyone complain that they have been the victim of over communication! An initial communication out to the organisation explaining the strategy and the approach to achieving it is a great start. But ongoing updates are necessary as progress is made and as strategy and approach is revised. New team members need to be inducted and provided the big picture before they join.

Evolution not Revolution

Change is hard. Many people don’t like change and there is always an organisational inertia dictating the practical pace of change that depends on the organisational culture and size. Ideally the changes in process and organisational structure required to make an organisation capable of truly Agile software development should be introduced gradually. In other words it is better to start small and gather momentum, allowing time to sort out the wrinkles that will appear. This strategy applies to both a large multi-team programme and to organisational adoption.

Assuming that there are already one or more teams successfully delivering good quality software every iteration, build the existing team sizes with a gradual addition of new team members. Get these new team members trained in the fundamental principles of Agile and the mechanics of your chosen Agile framework (e.g. Scrum). Make sure that the new team members are paired with experienced team members and allow for the drop in productivity that will occur while time is spent bringing the new blood up to speed. Grow the teams above their optimal size for productivity and then divide the teams in two with a balanced mix of experienced and new team members in each new team. Repeat this process until you have the required level of scale.

Organisational Change

As the number of Agile teams increases, the conflicts with the way Agile works and the existing way the organisation works will surface. To smooth the adoption, a parallel change programme should run alongside to gradually align the two worlds. An approach that works well is to run this change programme on an Agile footing, with its own prioritised backlog of change tasks – Ken Schwaber calls this the “Transition Backlog”. This approach has a natural empathy as it supports the flexibility to incorporate new tasks that arise out of the Agile teams trying to build software and it also helps align management to an Agile mindset.

Part 3 to follow

In part 3 I will talk about some of the approaches and patterns for enabling multiple teams to work in concert.

I recently ran into a problem using TFS Source control on a new laptop where the buttons and icons in the "Compare" dialog box and screen came up blank, leaving me to guess which was which.

So if you get this really helpful set of icons:

Or these really helpful buttons:

Then you have the same issue.

I initially thought it was the NVIDIA drivers for the display but it turns out that this problem occurs with McAfee VirusScan ver 8.0.0 and the "Buffer Overflow Protection" feature. I'm not sure whether it is McAfee or Microsoft code at fault. 

The workaround is to go into the VirusScan Console and disable the "Buffer Overflow Protection". This will obviously mean a reduced level of protection from your virus scanner. Apparently, this setting can also cause blank list boxes when binding to a collection.

Ok so we've released Scrum for Team System and so far about 550 people all round the world have downloaded it. What next then?

Well we are starting to think about additional tools and enhancements and would love to have your top feature requests. Just to fuel your thoughts, we are currently productionisng a tool we built for testing the plug-in that will allow you to move projects and all their history data between different methodologies. So for example you can take an MSF Agile project and convert it to Scrum. Another use for this tool will to enable Scrum for Team System projects to be moved to future releases of the plug-in.

Talking about future releases we are looking to do a minor release (1.1) in early May that will tidy a few things up. Keep a watch on www.scrumforteamsystem.com for details.

Please email your ideas for enhancements to scrumforteamsystem@conchango.com.

I co-presented 'The Value of Agile Methods' at the Microsoft Architecture Forum on Monday along with a colleague Howard van Rooijen. The presentation discussed the shortcomings of traditional software development approaches, before looking at agile methods and engineering practices that we have found help deliver quality software with features that the business actually need. Here at Conchango we have adopted a combination of Scrum and engineering practices derived from XP and this is what the meat of the presentation material covers.  

Microsoft has posted an early version of our combined slide deck and this can be downloaded from here.

Howard has published his final version slides with extensive notes on his blog.

My slides have quite a few custom animations in them with the result that the message may get lost in the translation to jpeg so I've decided to leave them in PPT format on the link above rather than including them in this post.

We had very good feedback after the presentation and it was a shame that we didn't get more time to answer the many questions. It was interesting that the questions and concerns were not with the concept of agile methods but more about how to persuade organisations to adopt agile approaches, with the most common obstacle seen as the dreaded 'Fixed price - fixed scope' impasse.

Sadly there is no instant silver bullet answer to this problem with the reality being that culture takes far longer to change than technology. The big problem is this illusion of fixed scope. This could only be a real concept if the requirements could be recorded in such a way that they were 100% rigorous, complete and unambiguous. Having achieved this impractical aim the requirements would then have to remain unchanged through to the time the software gets delivered. Life isn't like that, well at least mine isn't! An interesting example of the impedance caused by the written word occurred in the panel Q&A session at the end of the Architect Forum. Delegates wrote down their questions for the panel on post-it notes that were then read out by the facilitator. Almost every single question needed to be qualified verbally before we could be sure we understood the question enough to begin answering it.

So we give up and admit that we don't fully understand the requirements at the start of the project and we know they'll change anyway by the time we're done. This makes it somewhat problematic when trying to gain budget approval or bidding for a project. A certain amount of education needs to take place in the corporate world to make it understand that specifying and building software is far from the exact science that it is generally assumed to be.

When we engage with a customer we explain the futility of the fixed scope concept and rather than fix the scope we agree a fixed price to suit the budget. We then incrementally deliver the most valuable features, as prioritised by the business, until either we reach the end of the budget or achieve enough value from the delivered features. This approach does require a level of trust between the parties and has a much greater chance of success when the relationship works as a partnership rather than a customer-supplier arrangement.

Another colleague has a post dealing with the change in approach required from the Project Manager's perspective when dealing with the cost-scope-time triangle. Find this here on Steve Garnett's Blog.