|
|
-
I often talk with teams about why software projects fail, yet we have answers. We have modern engineering practices that give us faster technical feedback, reducing technical and integration issues and resulting in higher quality products. We have ways to work more effectively with our customers, reducing the risk that we deliver the wrong products and features.
It is usually not software development that is broken (although it often gets the blame), but something else that is stopping us really getting the benefits out of modern software development techniques, we usually find it is some other dysfunction within the wider organisation. It is these organisational constraints that make it harder for us to deliver quality products and services to our customers. It is these constraints that limit our ability to be Agile, and sometimes this is fine, but we should recognise them as areas for potential improvement.
On Tuesday 9th March 2010 Simon Bennett and I ran a simulation at the Scrum Gathering in Orlando that demonstrated one of the common dysfunctions we see in organisations: how we incentivise people. This dysfunction stops teams from self-organising and doing their job, tying them up in internal conflicts. The Incentive Trap took participants on a journey of discovery in terms of their behaviour; the simulation illustrated different incentive schemes resulting in a variety of behaviours, bringing out different feelings depending on how participants were rewarded for doing their job.
Feelings in the simulation ran high, we had guilt and frustration, received death threats (hopefully he was joking) and saw teams coming close to industrial disputes. Other teams on a different reward scheme had a very positive experience where the team was able to achieve rhythm and clarity of purpose resulting in a lot of value being returned to a high quality.
The obvious conclusion was that we need to pay attention to how we incentivise people and many of us have got it wrong. We hope to run the Incentive Trap at Agile 2010, so if you were in our session at Orlando please give some feedback on the Agile 2010 selection site. We thank all the participants who joined our session, we hope it got you thinking; we had a lot of fun running it.
Agile Software Development will not solve organisational dysfunctions, we need to reach out and work with the wider organisation and find ways to talk their language. It is not about being more or less Agile; it’s about helping our organisations get better at achieving their purpose.
|
-
At the Munich Scrum Gathering last week, Harvey Wheaton from Supermassive Games did a presentation entitled “Growing Self Organising Teams”, which was exceptional and I found it very inspiring, the presentation can be found on the Scrum Alliance web-site. In the presentation one slide caught my attention and it was how the team had used a Cool Wall, inspired by Top Gear (popular car show in the UK). I thought that would be an excellent tool for a retrospective and used it at the next opportunity, this is how I used it. Picture not great, but you get the idea…
Using the Cool Wall to Gather Data
The team was asked brainstorm team practices/team customs/patterns/ways of working, each team member then took it in turn to add their practice to the cool wall, and share it with the rest of the team. Sub-zero was for practices where the team felt they were world class, seriously un-cool was reserved for practices that really weren’t working.
I then asked the team to vote for the practice they wanted to work on, I had forgotten my sticky dots so we used marker pens. The team actually picked a practice from Un-Cool as the stuff in seriously un-cool was out of their sphere of influence and the ScrumMaster was dealing with it already.
Using the Cool Wall to Drive out Actions
Once we had selected a practice we had some discussion to understand the root cause. We then moved to generating actions by asking ourselves what we need to do to move this practice one column to the right. Remember you only want a few actions otherwise nothing will get done.
Check-out
To keep with the car theme I then asked the team to say given their project, what mode of transport they most felt like.
Summary
The approach worked well and really helped to create a picture of the work the team does, and uncovered loads of stuff that the ScrumMaster could work on to help the team improve. Also we only spent an hour doing it.
|
-
Next Tuesday I am speaking at the Munich Scrum Gathering on how Scrum deals with Risk. I am very excited about the session as I believe we often talk about how Agile drives down risk, but we rarely explore the topic that deeply. This will be a talk based on my practical experience working on both traditional projects and Agile projects, I will also create an opportunity for those that join me in the session to participate and share their experiences.
I have identified 4 main user roles that this session is targeted at, firstly the Product Owner who wants some practical tools to help them understand how the decisions they make affect the risk on the project. The Product Owner also seeks some guidance as to when we deal with Risk on a Scrum project.
The traditional Project Manager who is curious about Scrum, wants to understand if they should be doing risk management in the Agile world, what elements of risk management are appropriate and what tools from the traditional world are still applicable. The Project Manager is also keen to get some insight into just how Scrum mitigates risk and what risks we should be dealing with.
The Agilist wants to know if risk management is important on a Scrum project and gain some insight into why this is so.
The executive wants to understand who is responsible for risk and wants to understand how they will know if the team are paying enough attention to risk. The executive also wants to know how to cultivate an environment where risks can be dealt with.
I will be asserting that Scrum is move effective at dealing with Risk than traditional risk management approaches, and that traditional management approaches actually make some risks more likely.
I will be writing up my thoughts on risk and Scrum in the near future.
|
-
The "Situational Leadership" model, developed by Hersey & Blanchard, shows us how good leaders can adapt their behavior depending on an individual’s competence and commitment to achieving a specific goal or task. Through my work coaching Agile teams I have become aware that different teams require different approaches. Teams just starting out will need more direction to get up and running, as they will have low competence in Agile techniques. As teams start to get some experience they will run into challenges thus requiring more supportive behavior. As the team grows in competence less direction needs to be given. Eventually the team will grow in confidence and be able to be fully responsible for its own actions. I will call how I adapt my approach “Situational Coaching”, but it pretty much follows the Situational Leadership model.
Teams
Teams take time to form and they can be at different levels of competence and have different levels of commitment, as they atempt to achieve a specific goal.
D1 - Low Competence, High Commitment - in general these teams are lacking the specific skills and techniques, they are new to Agile, but they have the confidence and/or motivation to want to try it.
D2 - Some Competence, Low Commitment – the team now have some Agile experience, but still need assistance, changes in the team’s way of working may have challenged them or their organisation, their confidence may have taken a knock. They may be considering if moving to Agile was such a good idea.
D3 - High Competence, Variable Commitment – the team is now experienced and they are competent, but may lack confidence to work without the support of the coach, or they may lack motivation.
D4 - High Competence, High Commitment – experienced and comfortable in their own ability to work as a team. This team may even be more skilled than the coach.
Coaches Behaviour
Then there are four coaching styles to be used depending on how the coach assesses the competence and commitment levels of the team.
S1 - Directing – coach focuses on giving direction. The coach is telling the team what they need to do and makes sure they do it. To be used with D1 teams.
S2 - Guiding – still some direction but with a lot more support. There should be two-way communication; the team still needs direction, as they lack experience and some commitment. The coach seeks solutions from the team first, but will not let the team make too many bad choices and will therefore be prepared to overrule the team. To be used with D2 teams.
S3 - Supporting – less direction needed, but still offering a lot of support. The team now makes its own decisions. For teams with competence but lacking in motivation or confidence. They need less direction because of skills, but still need a coach to boost their confidence and/or motivation level. To be used with D3 teams.
S4 - Delegating – the coach needs to give little direction or support. This is for teams who have high competence and high confidence/motivation level. The team decides when the coach needs to be involved. To be used with D4 teams.
The coach should identify where the team are and work to move the Team from D1, to D2, to D3, through to D4. With different skills or situations teams may be at different levels of development, therefore a coach may behave differently depending on the situation or practice that the team are trying to master. The coach should be wary as teams can regress as well as move forward, sometimes external factors knock the teams confidence moving them back from D4 to D3.
|
-
It was at the Spring Scrum Gathering 2008 Chicago that Tobias Mayer did an Open Space session on simulations to help get Agile ideas across to people, in a way that brings them to life. One that was new for me at the time was the ball game, originally blogged about by Boris Gloger.
I have been using this simulation regularly on my Agile training courses, as I get more familiar with the game I have started to get better results in terms of the learning’s coming out. Yesterday I had the best results yet, which is why I wanted to write this blog. I am not going to give away what the team did, but I do want to talk about what and how they learned.
The basic rules are – the whole group is one big team, the balls (tennis balls or those soft squidgy balls are good, probably not cricket balls) are taken from a container and passed amongst the whole team back into the same container (a bin often works well), this equals one point, however:
The balls must have air time
Balls that hit the floor don’t count, and have to be returned to the starting point to get them back in play
No balls to your direct neighbour
Start point = End point (i.e. the container)
Iteration = 2 minutes
In between = 1 minute, to review and plan
Play 5 iterations
To set the game up you explain the rules, let them plan for a minute and then ask for an estimate of how many balls they will score in the iteration. The planning and estimating then happens before each iteration.
The number of balls that a team successfully return to the container will very much depend on the number of people you have, the number of balls you have and how long you make your iterations. Yesterday while co-training with Matt Roadnight we did this with a team that managed a 600%+ productivity increase by the end of the exercise; it was a team of 10 with 8 balls doing two minute iterations, results below:
The wonderful thing about this game is that the learning’s are always valuable but depending how the game goes different things stand out.
In the first iteration the team started out with a good strategy and was reasonably pleased that they smashed their estimate. I was a little worried because I thought they might struggle to find much improvement. In the second iteration they made a small adjustment which allowed them to improve, by the end of the third iteration their estimate was very good compared to their actual.
Learning 1 – Teams become predictable
The team had got into a rhythm of delivering balls through the system; their performance had reached a plateau, which is great because the team become predictable, as they get better at estimating based on their history of delivering.
I thought that maybe the team was as productive as it could be, I decided to push them a bit, as Product Owner I said I wanted more, I had seen other teams do a lot better than this after 3 iterations, I wanted 75 balls. Now I do this to see if they will take the bait, without major change to how they were working there was no way they could have done what I asked for. They did take the bait, but they also came up with a major improvement which allowed them to smash even my challenge.
Learning 2 – Removing impediments can lead to significant improvements
By the end of iteration 3 some people may have assumed that the team was hyper productive, but actually they had probably just reached an organisation impediment that was stopping them becoming more productive. Within their environment they had made a number of small changes that led to the plateau in performance, they had reached an organisational ceiling. However in the planning for iteration 4 the team challenged two assumptions they had about the game, and thus removed some constraints, very similar to changing a process that was constraining them.
Learning 3 – The power of Inspect and Adapt
This is the most important thing that comes out of the simulation. In the debrief I always ask the team what do they think would have happened if I would have got you to spend 15 minutes to do as many balls as you could, rather than having two minute iterations with a 1 minute opportunity to reflect and plan. The obvious conclusion that the team came to was that they would have at best carried on at a rate of 24 balls every couple of minutes, but would have probably slowed down, or even resigned due to boredom before the 15 minutes was up. They certainly wouldn’t have identified those major improvements that allowed them to exceed my challenge in iteration 4. Taking time out to Inspect and Adapt is investment time, but if it can improve the teams performance by 600% after 5 iterations it pays for itself.
Leaning 4 – Agile can be fun and it helps build a sense of team
The iteration gives the team a short sharp focus to try and achieve something together; they get this regular reward as a team of having achieved something. Participants also got more collaborative and the ideas started flowing the more success they had.
Learning 5 – Knowing where you are in the Sprint helps the team focus on achieving the goal
This was an unexpected learning. In the 3rd and 5th iteration Matt called out the timings every 30 seconds or so. We expected them to start rushing to achieve their goal, and start to drop balls. What actually happened was that because they had a realistic goal, the team visibly concentrated more on what they were doing. This is like the team glancing over at their Sprint burndown, identifying that things were going ok, but focusing that little bit more just to make sure no balls were dropped.
Other learning’s
Other learning’s I have had out of this game in the past include:
· In order to maximize flow it helps to limit work in progress.
· If the team tries to speed up to achieve a goal (i.e. I say give me 75 and they don’t make any improvements), they will drop more balls, this is like introducing bugs by trying to get through more features.
|
-
I was recently catching up with an old friend from school; he was interested in Scrum, as he had started to get requests for proposals that specifically asked for Agile. We were on a Stag do at the point of the initial conversation, so I probably didn’t articulate what Scrum was that well, and even if I did my friend was in no position to remember anything I said. So when I had recovered I jotted down some (quick) thoughts for him, he was particularly interested in how you manage a Scrum project and how you get started. Here were my thoughts designed to wet his appetite:
Scrum is not a methodology with all the steps that people can follow and get results, its not really a process. Scrum is an Agile management framework, that has a simple set of rules with the goal of frequently delivering valuable increments of working software to the customer.
Now you were particularly interested in how you manage Scrum projects: Scrum is actually a total paradigm shift in how we manage projects. In software developments we have struggled with late delivery, ballooning scope, technical problems, mistrust between the business and IT. With traditional management approaches we try to control this through more up front planning, tie down scope and sign it off, detailed upfront design documents, expensive tools to support methodologies, teams dedicated to assure quality and strict change control. In Agile we are trying to solve the same problems but in a very different way. Software development is a complex business that you can't plan out upfront; we need to allow room for creativity and innovation. Therefore Agile is about generating feedback so that the project can be driven forward in the right direction, we generate feedback by both the business and IT working together throughout the project to try and achieve a shared goal and by delivering the most valuable vertical slices of end to end functionality, not just a prototype but software in the real technology, fully tested, fully integrated and with no known quality issues, it may not do very much but what it does it does well. Scrum works by harnessing the benefits from having a self-organising team, who take responsibility for what they deliver, they are cross-functional in that they have all the skills to build something of value in an iteration (Sprint), that will give feedback, the team make a commitment to the business at the start of the iteration as to what they can deliver they are then responsible for delivering on that commitment. Managing Scrum projects is nothing about control, but all about creating the right environment where the team can achieve their commitments, it’s about removing the problems that are preventing the team from delivering, it is about coaching the team to a higher state of productivity and quality. Control in Scrum comes from having hyper-productive teams that can deliver regularly and in a predictable manner, if you have a dedicated team, you understand how much working software they can get through each iteration, you can start to make commitments around that.
You asked about how you would start up a Scrum project, and the short answer is you just start, there is no big up front planning needed. You probably need a business case and a Vision for what you are trying to achieve and a prioritised list of things to do (in Scrum this is the product backlog and it needs to be stocked with at least enough for the first iteration). Now you may need to setup environments, do some initial design, set-up continuous integration, etc…, but equally these can just be the first things on your list that the team do, we want the team to take responsibility for all aspects of the project, as they will know most about the problem they are trying to solve. What I would do is have the team go through a 1 or 2 day Scrum/Agile training course at the start of the project, we want them to take responsibility it is only fair to tell them what we expect of them, it also works as a good team building exercise. Ideally this training would be followed up by support from an experienced Agile Coach, as you can see this type of environment is very different from a traditional one, it is very easy to fail without that support.
For more information about Scrum see our process guidance at:
http://www.scrumforteamsystem.com/processguidance/
|
-
Lots of work has been done to understand the role of the ScrumMaster, there has been far less written and said about the role of the Product Owner. Who is this person who is responsible for the ROI of the project? I have tried to create a number of statements that balance the characteristics of the Product Owner.
Characteristics of a Product Owner
Understands thoroughly the needs of the customer YET they understand what it takes to build software
Senior enough to make the decisions YET they are available to the team
Knows when to say no YET they have a good working relationship with stakeholders and the team
Understands how to create value YET they trust the team to get the work done
Understands thoroughly the needs of the customer YET they understand what it takes to build software
The Product Owner is the voice of the customer therefore they must understand thoroughly the needs of the customer. In order to do this they will need to be out talking to customers on a regular basis and have a good understanding of their customers business domain. Yet, the Product Owner needs to have an appreciation of what is involved in technically providing a solution, this is essential to get buy in from the team. Asking the team to do something very difficult in a short amount of time will drive the wrong behaviors out of the team.
Senior enough to make the decisions YET they are available to the team
The Product Owner needs to be empowered to make the decisions about the direction of the project, therefore it is somebody who is trusted by the customer organisation, yet they are available to the team during the Sprint, therefore being Product Owner for the product has to be their day job.
Knows when to say no YET they have a good working relationship with stakeholders and the team
The Product Owner proactively manages the interest of stakeholders and takes advice from the team on dependencies however they are also responsible to ensure priorities are such that the maximum ROI is achieved, therefore they need to be able to say no, yet do it in such a way that everybody understands why the decision has been taken, so that everybody has trust in the Product Owner. The Product Owner needs to be able to take everyone on a journey with them.
Understands how to create value YET they trust the team to get the work done
The Product Owner needs to understand what value the user or customer will get by prioritising one particular feature over another, yet they are not the person who decides how this is technically achieved, they need to trust the team to get the work done, and help the team by providing feedback.
|
-
IT projects failures are unfortunately not uncommon. We hear stories of projects that never deliver, projects that are either late or well over cost. One of the main reasons identified for this is Scope being out of control.
In waterfall projects all the scope is identified at beginning of the project, when we engage with our customers here the emphasis is on making sure we have all the requirements as it will be expensive to change them further down the process. Therefore the customer imagines all the things they could possibly want out of this project and typically they throw everything in including the kitchen sink, because they know it will cost them if they think of it later. The result of this is we build a lot of features that have little value and/or will never be used.
Also because the customer is often only really engaged at the requirements gathering stage, as the requirements are handed off from one group of specialists to another, defects start to creep in. See tree attachment for illustration of this idea, the clasic cartoon.
Worse still what the customer wants by then end of the project has probably changed, their business has moved on. The end result can be mistrust and blame between the customer and the IT supplier.
Scope Management in Scrum
In Scrum we embrace change, we accept it happens and we try to keep the cost of change down by ensuring a constant flow of valuable software to our customers, using good engineering practices which keep the cost of change low and by involving the customer throughout as part of the team. Yet I still come across Scrum projects that struggle around scope, where the customer perceives they are not getting what they asked for, and that mistrust starts to build up between the customer and supplier.
It is widely accepted that in a software project you can’t fix Cost (people, equipment, etc), Scope (what we are going to build) and Time (when we are going to finish), otherwise it is ultimately Quality that suffers, because we work our team harder, or we ask the team to cut corners, usually both. Yet our customers want to know what they are going to get for their money and when it is going to be finished. Unfortunately this is where as an industry we fail, rather than saying ‘I’m sorry that’s not how it works’, we are all too ready to fix all the corners of the iron triangle, even though we are setting ourselves up for failure or at least a good chance that it is perceived as a failure.
Our customers are so used to getting their demands accepted by their suppliers that it makes it very difficult to get them to see that they would get a much better product if they didn’t fix scope, cost and time. I could talk about what to do if you have fixed scope, cost and time, as many Scrum projects end up that way, but I am not going to because I think we all have a duty to try to change that. Whatever approach you take in software development fixing them all will increase the chances of failure.
In Scrum it is usually Scope that we see as the best variable to be able to adjust. We know we have a big release at the end of July and we have got a fixed budget, therefore scope is the one left open to us. Scrum allows us to Inspect and Adapt so we can always make sure we are building the most important features, this works only if the customer (Product Owner) is involved throughout the project and they understand how to maximize their return on investment.
The Scrum projects that I see struggling with scope are usually those that haven’t got a customer working as part of the team, or they don’t understand how to behave as a Product Owner. The key is education, education, education and we need to start as early as possible. When the contracts are being signed make sure we don’t set ourselves up to fail, engage with the client and do everything possible to persuade them that by working together we can achieve the best possible results. It always amazes me that customers are prepared to hand over all that money and responsibility to the supplier; they wouldn’t do that for any other complex project, so why do they do this in software development? Because they don’t understand it scares them, it is easier for them to hand off all of the risk to the supplier. It doesn’t have to be this way, make it a collaborative venture, play the game together and share the risk. Make our contracts more about how we will work together, possible future blog.
When you have your customer as part of your team, make sure they know what is expected of them. Education is one of the responsibilities of the ScrumMaster. The key thing that teams struggle with is their scope not being managed well; make sure the Product Backlog is in a good shape for planning. In a future blog I will look at Product Backlog farming, the ongoing effort the product owner and team need go through to make sure the backlog is just good enough for Sprint Planning to occur.
If the Product Owner has an understanding of the teams velocity and has an estimated Product Backlog, they will be in an excellent position to make trade off calls around scope. I often find that teams don’t have a Product Backlog Burndown, this is a sign that teams don’t know where they are in terms of burning through the work. We measure ourselves against how much working software we have done, therefore the lack of a Product Backlog Burndown is usually an indicator that we (including the customer) don’t know how much work is left. A dangerous position to be in and one that could lead to the blame game, when it turns out we are not where people assumed we were.
Summary
· Don’t fix scope, cost and time, we need to change the expectations of our customers.
· Involve the customer as part of the team; make things visible to them throughout.
· Educate the customer so they understand what is expected of them, give them training.
|
-
It’s something that people always ask ‘how do we manage bugs in Scrum?’ or ‘what do we do with the bugs at the end of a Sprint?’. I always try to make people understand that they are asking the wrong question, what they should be asking is ‘how do we make sure we don’t have any bugs at the end of the Sprint?’.
The output from a Sprint should not be considered done if it has bugs against it. During a Sprint, a Backlog Item needs to satisfy its Acceptance Criteria before it can be considered done, therefore if any team member finds a problem that would cause the Product Backlog Item to fail its acceptance criteria then it is just another task that needs to be completed before the Item can be considered done. As such this would result in the Item returning to the Product Backlog.
If a bug is discovered on work previously considered done it should either be fixed (if it is a trivial matter and can quickly be fixed) or if it is a significant piece of work then it needs to be prioritised with other work in the Product Backlog. Everything we do should add value, equally everything we do has a cost associated with it, in Scrum it is the Product Owner who owns the Return On Investment by balancing these considerations.
Not all bugs necessarily need to be fixed before the Product Owner will be willing to release, but this should be a business decision. No longer should developers and testers need to get into arguments about the value of fixing a particular bug. This highlights the need to have a good Product Owner who is part of the team, as they should understand the cost of not fixing the bug. If something is found which the Product Owner sees no value in fixing in the near future then there is no value in recording it, in fact it is waste to have to manage it.
If a bug is identified then two things need to happen:
1. The bug needs to be fixed
2. The team needs to investigate why the bug was introduced, and take corrective actions to make sure it can never happen again
Having a large number of bugs at any one time means that it is going to be very difficult to understand the true quality of the system and where we really are in the project. Without the second part you are never going to improve you are always going to be bug fighting, rather than building quality into to your software from the start. This may involve writing an automated test to make sure the bug never comes back, changing how team members work together or changing coding standards, once you understand how the bug was introduced you can take appropriate action. People will argue that you are always going to have bugs due to the nature of software development, which may be true especially in a complex environment with a large team; however this is totally the wrong attitude and is the reason we have so much buggy software. Therefore we need to be careful that people don’t use this as an excuse to write poor quality software. We need to at least target ‘no known bugs’ in our definition of done and focus on building quality in. If bugs have been reported in the software and the team knows about it at the end of the sprint how can they say the story is complete? The answer should be they can’t and therefore the story should be not considered done. Focusing on good engineering practices, building quality in, and a stop the line culture allows teams to never be far from a shipable product. Good Scrum teams often find they don’t need a bug tracking system, because the question ‘how do we manage bugs?’ becomes irrelevant.
|
-
On Wednesday 6th August I shall be delivering an experience report at Agile 2008. I have attached my paper and presentation for your convenience. If you saw the presentation or you have comments on the experience report then I would love to hear your feedback.
Abstract
This paper is an experience report from my time working at CampusSoft in the UK. The focus is on their experiences using Agile in a multi-site software development environment, spread across the UK, Romania and India. We will start by looking at the motivations behind outsourcing some of their work to India and why the relationship with their partners in India led them to try using an Agile approach. We will then look at some of the approaches which were important for them to be Agile and the challenges that they faced, such as communication, working practices and culture.
|
|
|
|