Getting Started in Agile
|Risk Map||Risk Map|
|Getting Started in Agile||Getting Started|
- 1 Getting Started in Agile Software Development
- 2 Alternative Strategies
- 3 Conversation Snippets
Getting Started in Agile Software Development
Many teams who attempt Agile Software Development fail in their attempt. Some succeed; some try again until they succeed. The purpose of this document is to give a few tips that should make success more likely. This is particularly suited to cases where the project context is not in that 'sweet spot' where the standard set of agile practices work well.
Historically, “Agile” is empirical; we tried things and kept those that worked. This led to a drive to establish the ideal context in which the agile practices could work – small teams; customer on site; co-location; self-organizing teams. Now there is a need to expand into areas where the ideal context cannot be established, and that needs a theory underpinning why the agile practices work. For that theory we go to Lean Software Development.
There are two main strategies for adopting Agile Software Development. Let’s call them the Big Bang approach where the team goes all out to become agile in one big step change, and the Baby Steps approach where the team becomes more agile in a series of small but readily manageable and relatively safe steps. These are discussed later in this article.
Each of these approaches has its own difficulties, and there are a few common difficulties that could be experienced no matter which approach is taken.
|Safety Net :||How to keep on track|
|Practices, Principles and Values :||How to choose the right thing to do|
|Team Work, Team Problems, Team Successes :||How to work as a team|
|Collaborative Communication :||How to communicate efficiently|
|Zero Technical Debt :||How to avoid degradation|
|Knowledge Transfer :||How to find and share knowledge|
consider : Build quality in… Eliminate waste… Defer commitment… Deliver Fast… Optimise the whole; - as topics to include in the future.
Whatever approach is taken, it is essential to get the Safety Net in place.
Let’s talk of Agile Software Development by comparing it to the modern Agile Fighter Aircraft. This aircraft is inherently unstable. If left alone without active control input it will rapidly go off course. What makes it work is a tight feedback loop. The direction is checked very frequently, and corrections to put the aircraft back on track are given all the time. But why should we want an aircraft that is so unstable? Because if we want to change direction we can change direction very quickly; there is almost no inertia to overcome. Similarly, in Agile Software Development we need this tight feedback loop. We need to be able rapidly to detect when we go off track. We need to be able to correct the course in such a way that we get back on track. The gain is that by taking away all the heavyweight controls we can change direction as soon as we need to, and as often as we need to. Where there are frequent changes to the context or to the requirements this is a handy ability to have. Where there are many unknowns in the work we are doing, it is a very valuable ability to have.
So, we call this feedback loop the “Safety Net”. If it isn’t in place we will crash. There are two key parts to the Safety Net. First, it must detect that we are off track pretty soon after we go off track. Second, it must give a timely response to the situation that, crucially, will put us back on track. Note the several possible points of failure. The Safety Net may not detect that we are going off track. It may not detect in time. It may not give a good corrective response. It may not give the corrective response in time. On the other hand, look at the benefit if the Safety Net works. We will always be put back on track, in time. How can the project fail?
In reality, we spend a lot of our time perfecting this safety net, so that we can detect more types of failure; so we can detect problems sooner; so we can get better fixes for the problem; so we can use more stringent measures for “off track”; so we become ever more efficient at delivering value. Yet the major cause of failure in adopting ‘agile’ is not getting this safety net in place at all.
There are other names for the Safety Net; e.g. Scrum uses the phrase “Inspect and Adapt”. Some approaches don’t explicitly mention the concept, but have sets of practices that ensure it is covered. Running Retrospectives at the end of an iteration is not enough on its own – can you afford to wait until the end of the iteration to find you have gone off track?
This topic is marked as “Essential”. You must get this working or you will fail.
Practices, Principles and Values
Agile Software Development is not about the Practices, it’s about the Values and Principles. But as you start adopting Agile Software Development we do not expect you to have that deep belief in the values; to have the knowledge and experience to understand and apply the principles appropriately. What you are left with are the Practices. But the practices used in absence of the values and principles are not enough.
Let’s take another analogy. Suppose you have been taught how to steer the car. You are left on your own to steer the car for a while, and then somebody comes up, looks out of the windscreen and asks, “Where’s the road?”. You might have been turning the wheel as you have seen other people turning the wheel. You haven’t grasped that the purpose of steering is to keep the car on the road. Sure, that will never happen to you; we all know Why we steer a car. Yet look again at a young child – they emulate the turns of the steering wheel but don’t relate them to the turns in the road.
Understanding Why you are using a particular practice, what it is meant to do for the overall process, what to expect when it’s going right, what to expect when it isn’t going right; these are all parts of the Safety Net.
- Kent Beck:
- "I think the easy part of XP is practice related, but there is 3 legs on the stool: practices, values and principles; and I think people who are successful applying XP are paying attention to all 3. This gets back a little bit to some of my disenchantment with the direction of agile development in general, people are now asking the question: "How am I going to do agile development?" and agile development isn't a thing you do, it's an attitude, it's a set of personal values about responding to the real world, being open to the information that is there and being willing to do something about it.
- That is agility. Yes, there is a lot of practices that come out of that but to me that is where it starts, it's this attitude. If somebody understood a bunch of practices and tried to do them, you could do agile development without being agile and it's a disaster because you're acting out of harmony with what you really believe when you do that."
- from InfoQ: Beck interview
So, how are we going to get around this problem? The best way is to work alongside somebody who IS well immersed in the values and principles; to discuss ideas and issues with, to take advice from this person. This person can help act as the Safety Net… but the team members must not absolve themselves from all responsibility for success or failure, or they will fail. The expert is there to catch you when you fall, but you must try not to need him.
Without this help, the only recourse is to extra measurement, extra reflection, extra research and reading; and above all, scrupulous honesty about when and why things go wrong. Some people succeed through this route. It isn’t the easy option.
There are goals for a coherent process; you must know how to keep on track, you must know how to choose the right thing to do, how to work as a team, how to communicate and transfer the knowledge efficiently and effectively, how to avoid storing up trouble and technical debt for the future, etc. Practices aren’t something you can mix and match with impunity; you need to keep the values, principles, purposes and your strategies in mind when making choices.
This topic is marked as “Essential”. It must be addressed or you will fail.
Team Work, Team Problems, Team Successes
One often hears about teamwork, harnessing the power of teams, etc. It is common for people to attend the courses, listen to the lectures, and go away saying “we do all that anyway”. Yet the first time they work on a truly collaborative team is a real eye-opener. At that time they begin to realise what the lecturer was talking about. They really ‘get it’ for the first time.
There are two aspects to teamwork that are high priority to address; Commitment and Ownership. Many agile teams favour working in 2 week iterations; this is about ideal for Commitment. A team can look at the work to be done, assess how long it will take, and commit meaningfully to a chunk of work that they believe will take no more than 2 weeks. Choosing longer periods tends to increase the frequency of over- or under-estimation and results in a lower degree of commitment to finishing that work in the estimated time. Important points: first, the team must decide how much they are committing to; the PM cannot make that decision for them. Second, the commitment is stronger than an estimate but weaker than a guarantee. The team will make their best effort to meet the commitment but we must accept that this will not always be possible. Third, the team makes the commitment on the basis of the totality of the work; this is not a set of individual commitments to individual tasks.
Ownership of the work, of the problems with the work, of the penalties and rewards, is at the team level. The only people allowed to allot work, problems, penalties and rewards among the team are the team members themselves.
- “We looked at the tasks on the task board. If any task was more than a couple of hours late, the entire team gathered round that person’s desks and helped out until the blockage was licked”
Team ownership is key to getting the team to work effectively; to organise themselves to find and solve all the problems, to spread the load, to meet the targets on all tasks not just one’s individual tasks. There are a few essentials that underpin this. The team must be co-located and capable of talking to each other openly to achieve best results. As much as possible must be done to reward working as a team and not reward putting one’s own interests in front of those of the team. Measure one level up; each team member gets rewarded based on the team’s performance. The Manager gets rewarded based on the performance of the team of his peers, etc.
This topic is marked as Highly Desirable. It is possible to succeed as a group of individuals who don’t go out of their way to help each other, but the ‘team’ will be no stronger than its weakest link.
"Can you get feedback within seconds?" - a touchstone to see how 'collaboratively' you are working.
All the real value that we add when developing software is added when we make decisions or when we make discoveries. The rest is just book-keeping, and we would like to keep this to a reasonable minimum. When we make discoveries or decisions, these are based on existing information. In order to work efficiently, we need to get the existing information from where it exists to where it is needed as efficiently as possible. In essence, any discovery or decision is made in a single person’s mind, once all the relevant information is assembled. Of course, there may be the need to ratify that decision with other stakeholders in that decision; similarly with discoveries.
Once we understand this viewpoint, there are a few clear observations. First; knowledge transfer is probably iterative. There may be several rounds of questions and answers before all the relevant information is assembled in the one person’s mind. Clearly this will work faster and better if the people are talking face to face. Second; there may be several stakeholders, several sources of relevant information; a response from one stakeholder may give rise to a question for another stakeholder. It helps if these stakeholders are all present at the same time. Third; it is easier to come to a decision when there are fewer people present; they each need to assimilate fewer different points of view. This works better where responsibilities are ‘chunky’ rather than finely divided. It is also easier when the individuals already understand the general concerns of other parties so they don’t have to assimilate a new point of view from scratch.
Also under this heading we will consider ad-hoc communication between team members. It is very helpful to have the core team co-located, where they are close enough to overhear conversations between other pairs of team members, to ask a neighbour to help, etc. This proximity is the only known timely way of dealing with the case where you don’t know that you need to know something that someone else knows.
This topic is marked as Highly Desirable. Poor communication will affect speed and efficiency. This effect can be so severe that it will make the difference between success and failure, particularly in a competitive environment.
Zero Technical Debt
Many of the agile ‘Engineering’ practices are concerned with reducing the “Technical Debt”. Many of the agile ‘Management’ practices assume zero technical debt.
One of the assumptions of most agile planning techniques is that it will cost the same amount to implement a feature if we do it in 6 months as it would if we were to do it tomorrow. Practices based on Waterfall techniques cannot meet this assumption. If we don’t plan to implement the feature now, there will be many changes to be made in 6 months’ time to implement the feature. This will incur greater cost. Therefore we need to know and start preparing for all features now, to minimise their ultimate overall cost. The important fact is: It doesn’t need to be that way.
There are 3 key practices that work to keep technical debt low. First, there is the fear that when we change things to add a new feature we will break something that already works. We counter this by a technique called Refactoring, that alters the structure of the code without altering its functionality using a set of well-known transformations. Second; despite our best efforts, Refactoring sometimes goes wrong. To deal with this we use a specific Safety Net – an efficient and complete set of Unit Tests that we run frequently so we can spot as soon as we have broken something that used to work. Third; we apply a few design principles that keep the design as simple as reasonably possible. This gives us a direction when we employ Refactoring. Now would be a good time to mention the Principles of Object-Oriented Development; these should already be known but some remedial study might be needed, particularly for those not using OO languages who probably think these principles don’t apply to them.
The outcome of keeping to these practices is that we need to make near enough the same changes when we come to add new functionality whether we do it today or in 6 months’ time. Thus the cost is near enough the same. As a result, we are not driven toward ‘Waterfall’ practices of making unnecessary preparations, of specifying unnecessary requirements just in case we find we need them later, etc.
This topic is marked as Desirable. However, do not underrate the topic because we do not call it Essential; if you do nothing you will be very inefficient and this could lead to failure. Yet any improvement from the worst case will bring rapid benefits, and we do not need to bring technical debt down to Zero immediately.
While too great a degree of specialisation is not as big an impediment to Agile Estimating and Planning as is Technical Debt, it is still an impediment. We need our people to be ‘fungible’ – they may specialise in certain topics but in general can put their hand to anything – provided they have access to te occasional guidance from the specialist in that area.
There are numerous alternative approaches and a myriad of practices to aid knowledge transfer. Probably the most contentious of the practices is Pair Programming.
On this particular topic, I favour telling the team that Knowledge Transfer is an important objective, and letting them choose any effective techniques and practices that they can live with or enjoy.
Knowledge Transfer is marked as Desirable. Lack of it may not kill a project, but it can become an impediment to efficiency, creating unnecessary bottlenecks.
Baby Steps Agile Adoption
How to become more efficient using modern methodologies by adopting them in easy steps.
As ever, the Safety Net is the most important area of practice to get working. In principle, we can use this to drive all the other changes that are needed, but it might be helpful to have a roadmap of where you want to be, which major changes are needed before you get there, and a timetable of goals to meet along this route.
It makes sense to start with a sensible Agile team size of around 8 team members to cover all development functions, though one could start with a larger team and split later. It is highly desirable to start in a location that permits collaborative communication – the team should be co-located and able to tune-in or tune-out on what the rest of the team are doing. Note that it will be hard to do this with larger team sizes, where it is inevitable that some team members cannot tune in to what the more remote team members are doing.
Adopting Agile Software Development in Baby Steps has two particular problems to be overcome
- so many of the practices have dependencies on other practices. Test-Driven Development is a good place to start – or its little brother Test-First Development. This drives good design practice and helps establish good collaborative communication among the team, and has few if any dependencies on other agile practices. A good next step is to work on the zero technical debt practices. Attaining a reasonable level in these will enable the more agile planning techniques to be employed; User Stories on a Product Backlog, Agile Estimating and Planning, etc.
- Adopting individual practices will make the change harder, as the agile mindset is not referred to as a whole. The software development system will bounce back to its original preferred state much easier than in big bang adoption.
A topic that can be brought in at any time, the sooner the better, is Knowledge Transfer. Some techniques and practices are dependent on others that may not yet be in place, but there is always some way forward. One may choose to adopt the other practices later.
Big Bang Agile Adoption
How to become more efficient using a modern methodology by adopting it all at once.
Big Bang agile adoption is contra-indicated if the context is not close to the ideal for Agile; if there are too many of the "Agile at Scale factors" in play.
There are two particular things that need to be in place when going for “big bang” agile adoption. First, you need to get the best possible help. With so many new things starting all at once, the need for an experienced eye is paramount. There will be so many things starting to go wrong that it is vital to prioritise. Second, you need to get a high level sponsor who can cut through the bureaucracy and remove impediments that are placed by other high-level people.
As ever, the Safety Net is the most important area of practice to get working. Until both the detection and correction of problems are working effectively, our brought-in expert help is necessary. A coherent set of Practices, usually Scrum and XP, should be the starting point for the Big Bang approach. No matter how much tuition is given in advance, any new practitioners will need guidance in most if not all of these practices. As is mentioned above though, performing the Practices is not enough; people need to know Why they are performing the Practices or they cannot make sensible decisions when it is time to adapt. Again, we cannot afford to let brought-in expertise go until at least one respected team member can live the values and apply the principles. The desired dynamics of the team should be supported by appropriate “carrot and stick” that drives the Team Work in the right direction. It may be the case that the team chooses to work in a healthy way without the appropriate carrot and stick, but an inappropriate reward and penalty system can become a major impediment. It is essential that the team Manager understands this, even if he has limited power to change corporate ways. When adopting a set of agile Practices, these would normally include a set aimed at establishing zero technical debt. The team does not need to get to zero immediately, but if ‘low’ technical debt is not achieved, this will become an impediment to correct working of other practices. With a good Safety Net process in place it is healthy to let this detect and correct the impediments. By doing this, the team will come to realise the value of the practices they are asked to adopt, will come to choose to adopt those Practices that address Technical Debt. It is important to ensure that the impediment is addressed rather than choosing to drop the practice that is being impeded. Essential if any serious improvements are to be realised is an area and a culture that supports collaborative communication. The team must be small enough to communicate collaboratively, and the supporting information sources from outside the team must be able to provide input more or less on demand. In reality, instant access to supporting information will always be patchy, and help from a high level sponsor may be needed to remove the more difficult impediments in this respect. Care must be taken, of course, not to alienate those whose input we need.
Here’s one way to do a “big Bang” approach to starting up in ‘Agile’…
- Robin Dymond – this from the AgileProjectManagement group on Yahoo …
- One advice I can offer is to take a single small cross-discipline requirement, and with the whole team, take it from idea to a working feature. Don't do any other work. Have the whole team work together for the WHOLE time. People may have to sit and wait, that is OK, however it is much better if they try to find ways to help each other. Talk about the process, talk about what each person is doing. Talk about how this is different than what they usually do. Talk about their frustrations working on this one feature, and the positive aspects. Then do it again. Ask the team what we can do differently to improve, while still all working on only that one feature together. Then do it again with a 3rd feature.
- After having to work 3 features, 1 at a time, the team should have a feeling of how this differs from what they were doing. They should also have a much better idea of what each person does. They are now in a better position to figure out a process that will work for them.