Everyone encounters challenges when moving to agile. What was yours? Tell us how you overcame a roadblock and you could win an Asus Eee PC Netbook.
We are looking for stories of how you became more agile despite a constraint within your company. To give you a feel for what we are looking for, some of the common constraints we encounter are:
- Multiple product owners
- Limited product owner availability
- Team maturity and the ability to self-manage
- Project team also supports production
- Regulatory requirements: SOX, GMPs, ISO
- Internal requirements for PMLC/SDLC
- Distributed team members
- Dependency on other departments
- Fixed bid work
How to enter
Entering is easy. Use the “Leave a reply” box at the bottom of this page to post your entry. Your entry should include:
1. The scenario. What agile principles were you pursuing when you encountered a roadblock? You can see the agile principles on the Agile Alliance website.
2. The solution. What did you do to overcome your constraint?
3. The result. What was the result of your solution?
Rules
1. Only one posting per person.
2. Submit your entry by 6 PM Eastern Time, August 28th, 2009.
3. Winner to be announced at 9 PM Eastern Time on August 28th, 2009.
Grand Prize
The person with the best submission will win an Asus Eec PC. This netbook is top rated and provides everything needed to be effective on the road, or when you are away from your main laptop or computer. You can see the specifications here.
Other Notes
The email address you enter will not be posted with your submission. We will only use it to contact you if you win. You can maintain anonymity for yourself and for your company if you want to maintain privacy.
The winner will be determined by reviewing votes on the submissions and by subjective review by the GS Solutions Group review team.
Not interested in entering? You can still help us by voting for your favorite entry by clicking on the “thumbs up” icon. The amount of votes received will factor into the selection process.
Why are we having a contest?
The purpose of this contest is to promote the services of GS Solutions Group and our blog, Agile in an Imperfect World. We are here to help you with training and establishing processes that allow you to deliver great projects. You can read more about our services here.
If you have questions about your submission, or the contest in general, you can email us at greg@gssolutionsgroup.com.
Situation: My team was working with multiple product owners for our product. We often had fights and disagreements over which product owner’s requests were the highest priority for our releases.
Solution: We worked with the product owners to create a request form that rated the value of the request on areas such as revenue generation, cost reduction, number of users affected, and complexity. This form allowed us to score the requests against each other and see their overall value to the enterprise.
We also established an overall enterprise product owner who would make the final call on features for a release if we could not get all product owners to reach agreement (we have rarely had to use this process).
Result: We still have some disagreements and arguments, but the scoring matrix gives us a better place to start when working with customers to finalize the features for a release.
Situation: The tension was so thick that the team was choking on it, yet no one could name the cause. It was affecting everyone, especially a small group of team members who were working on a new area of the product together. If you looked in on a typical conversation, you would think that these three hated each another. Raised voices, talking over one another, doing things “my way” regardless of what the others were doing – this was common. They were running (fast!) in three different directions at once. It wasn’t just the way they were working together; it was what they were producing that was a problem, too. The product owner felt their work was uninspired, too deep in some areas and too light in others. Worse, they were infecting the rest of the team.
When we got down to the core of the problem, we discovered that each of them had just received their yearly performance review and each of them had been told something like this by their functional manager, “To get the rating you want this year, you have to grab something and make it your own. We need to see results and see you driving those results.” Each of them took that to heart. They were grabbing work, they were grabbing air time, and they were grabbing each other by the throat. This only came to light through one-on-one coaching sessions with each of the players.
Solution: I (the agile coach) spoke with the functional managers to let them know the impact on these three and the larger team. I made no bones about it. I let them know the team would not meet its commitments if each person were incented to stake their own territory.
The managers were resistant because the “stake your territory” message was the one they were told to deliver by their manager. So I went to talk to that manager. Through our conversation, he realized how detrimental that message would be to his main goal which was to get more and better work through the agile teams.
Result: These three turned out fine. Once we realized what was going on, each shared their performance review plan for the coming year with the others and they realized why they had been working at cross purposes. The edict about staking territory was relaxed, the team understood one another better, past sins were forgiven and the team got back on track.
————————
A story like this will appear in my forthcoming book “Coaching Agile Teams.” If you’d like to get in on drafts of the book and help make it better, ask to join the private Facebook group called “Agile is more than…”
Scenario: Frequent delivery, within the iteration
Situation: Teams falling into mini-waterfalls, taking days to complete individual work, resulting in most testing coming at the end of the iteration. People were thinking of iterative as applying to the iteration as a whole, not their own work.
Solution: Coined the phrase “Iterative Development Happens in Your Head, not on the Calendar” and showed folks how to view development of a “module” as a series of incremental development episodes. For example,
1) Create the interfaces to other modules and test them;
2) Create the I/O “calls” and test them;
3) Create the “control structure” of the module and test that;
4) Add sequential data manipulation (in chunks based on control structure units) and test them.
The idea was to reduce their thinking to episodes of minutes/hours rather than days. This, of course, required testers to create their work in small increments as well.
Result: Shorter development cycles with greater confidence in code quality as well as, best of all, much closer and more frequent collaboration between developers and testers.
This did take ~3 iterations (2 weeks each) to get going well and it was still a struggle for some to get into this pattern. But, overall, people began to see what being truly iterative and incremental from an agile perspective was about.
Hi,
A few years ago a small government department came to me with an interesting problem. They needed a new core system and the project absolutely had to be an outstanding success. They had tried to build this system twice before and failed, but this time the very existence of the department hinged on being able to create this new system.
The key to solving this problem was of course to control risk, and to this end I recommended that we develop the system using extreme-programming (XP). XP insists that we deliver something of value to the business every two weeks — in this project that meant that two-week’s work was the most that could be lost if something went horribly wrong. Management really liked the idea of frequently and incrementally delivering value, and it was easy to explain to them (thanks to the brilliant work of Kent Beck who explained it so well to me).
Once they understood XP, the management team really bought into the concepts behind the agile approach to software development, and understood that ultimately people are responsible for delivering systems. They realised that the environment in which they put the development team would greatly affect their ability to deliver the system. So, they asked me to design the ‘perfect’ software development lab. The question caught me off guard, so I sketched out a design on a whiteboard. They liked it so much they invested about $100k building it.
They pulled down a couple of walls to enlarge a space on the top floor with a nice view of wooded hill. They had a round table built, with space for five pairs of developers each with two large screens. They built a long ‘war’ table, put in variable halogen lighting, smart whiteboards, a couple of projectors, and bought Herman Miller Aeron chairs. The breakout area had nice red-leather couches and a good coffee machine. Around the edges of the room were workstations for peripheral staff.
Once the lab was ready our attention turned to selecting ‘users’ to work with the development team providing stories and expert business knowledge. We brought in the assistant heads of each of the five business units in the department to work with us full time as the ‘user’ group. These brilliant people were 100% behind us and were constantly pushing us onwards. They took each iteration’s release back to their departments to socialise, so that as the releases rolled out, nobody was surprised by their content. This also gave a chance for the lower-ranking staff to have input into the process.
We had at our disposal the entire organisation and its staff. We could walk the floors and talk to anyone we liked. We regularly had open discussions on the direction the development was going and we would always be happy to have visitors to the war-room coming up to tell us about how they were using a new feature in an unexpected way, or how they’d find something really useful if only it worked in a certain way.
Combining the business knowledge of the user group mixed with the development team allowed us to synthesize a new way of achieving the department’s underlying mission. The approach is radical and has attracted academic interest from around the world.
The commitment to the human side of the project paid off handsomely. The project was a huge success and made the front page of the local computer press three times. The system we built is still being examined by experts the world over for it’s innovative solutions. And, the strength of the system can be seen in the fact that it can be used in domains other than the one for which it was originally intended.
The tools we used were the right tools for the job. More important however were our processes, which helped us actively reduce risks and constantly maintain visible progress which in turn helped safeguard the future of the organisation. Our process also helped us see clearly to the heart of the problem — people were our strength and only through them could we become successful.
People over process over tools!
Bryan
1
Last year there were some problems in my team.
The biggest problem was that the other sub teams scapegoat’ed the yellow sub team.
A lot of people came to me, complaining about the yellow team or complaining about team members but never talked about these issues in person.
I assembled everyone in a meeting room and told them I did not like that.
I told them that people came to me instead of talking to eachother.
And I wanted to them to bring it out on the table. I asked them to stay polite and to talk about the things they did not like, not about the persons.
And when someone talked about them not to take it personally.
When they talked about a persons that was not there. (Old team members) I asked them to concentrate on the persons who where present.
When they talked about a person present. I aksed them to talk directly to them.
(Not: I don’t like what Joppe did. But: Joppe, I don’t like it when you did this.)
During this first hour a lot of frustration was broughed up.
Surprisingly a lot was about project management.
There was some reorganisation a few months ago.
Let me state what I understand happened.
* The person that had my place before, asked the team to come up with idea’s for the reorg.
* That did not work out completely. è they did not have a solution
* After a while he and his/my boss took a decision
Basically the team was not ready to be a self-organizing team. Because the boss did take a decision they were even less a self-organising team afterwards.
And a week or so later while the boss was on Holiday One person created his own team. Both changes created frustration.
The persons that created his own teamtold the team during the meeting it was The boss idea. The boss was not present but told me afterwards that that was a lie.
Some more frustration was vented about stuff in the team.
So I then asked them split up for 30 minutes in groups of 4 people.
At least people from 2 of the sub teams, if possible from 3 or 4 teams.
We came back to another meeting room 30 minutes later.
Before everyone was there my boss & me did some explaination about scrum and agile as an answer to some questions.
(I also pointed them to a presentation that we cancelled that same day because of these problems.)
They did not have much answers except that we had to dismantle the yellow team.
Something I agreed to because I wanted to protect the Yellow team members from being burned completely. (They also started to have a reputation outside our team)
Nobody had an idea how to do it. Actually they wanted me and my boss to recreate new teams.
I did not wanted to do that as they had just said in the previous meeting they did not like the boss taking these decisions.
Then I heard myself saying: I have a scary and crazy idea.
I’m not sure if it is going to work, but I have something I would like you to try to create new teams.
We will rearrange the room. Move the tables to the side.
The next 20 minutes I want you to move around in the room to group yourself in 3 groups.
You move around until you think that the new division is the way you currently think our team should work.
A discussion started about what should be the rules for this division. I stopped the discussion and I said that it was impossible to have an agreement for these rules. It was much better that people moved around until they felt happy about the result. I asked them to really focus on their gut feeling.
The idea behind it is that your body knows these things a lot earlier then your brain does. (Not sure how I explained this).
And before we started I added one more constraint: they were not allowed to talk during these 20 minutes.
They started of very slow. I could not really see groups it was more like lines. So I asked to from really circles.
Then the movement really started.
After about 10 minutes the movement was over.
So I asked them, are we happy with this. (I felt they were not)
One person told me he was not but he could not change it. I told him he could move and maybe other people would also move around
I told them to move again.
Not much happened.
After a while I asked the question again.
The same person said; I’m still unhappy but I cant help it
I told him he could move 1 person by taking his shoulders and move him. He moved one person. I thoughed he did not put him to one team. My boss thinks he did. A lot of movement after that. (People left the new team of the moved person.) After a while we had almost the same teams as before the change.
We talked again.
Someone said that for him the biggest problem was that 4 or 5 core member of the Yellow team were back together.
So the original problem stayed.
It was kind of hard for the yellow team, which I found not fair as everyone moved, so it was not just these members who where responsible. Which I said.
I had the feeling they would get out of it. (I don’t think I had another solution ) so I told them we would try again and everyone could think about that constraint.
I also told them that my boss and I could come up with a solution but that it would be always less then the solution they would come up with.
I told them that because some people already said why don’t you decide. I did not want to decide as they just complained in the previous meeting that they did not wanted us to do that. So I told them that I refused that.
I told them that the IQ of 40 people was way higher then mine or my boss. We first had a small toilet break, where they could talk.
(5 minutes became 10)
And then we redid a walking around.
And sometimes later we ended up with 3 teams.
In total it took them between 90 and 120 minutes.
They still had a small discussion about the fact that one of the teams had no French persons. (Which was one of the rules they tried to create befor ethye started to move around) and actually other team members said this was not suc a big deal as the two other teams had all languages.
The creation of the team was a compromise. A compromise created by the team.
Unfortunately 3 people were not present.
The energy level the next day was incredible.
A lot more people do take responsibility.
For me it was the start of the self-organizing of the team.
The next day I also heard that the story was already told all around the post and that I’m starting to become famous. Not sure if that was good or bad.
Personally achieving this was one of the highlights of my life.
1. The scenario: We had challenges in ensuring “Business people and developers must work together daily throughout the project.”
The development team was in corporate head office. Business teams were geographically dispersed in three time zones. The task was to build one solution that fits all.
2. The solution. We realized early on that we needs a product owner from each business unit. But, team was getting pulled in different directions due to differing priorities for the business units. I worked with the product sponsors and got a proxy product owner on site. His job was to make sure the development team receives clear communication on what needs to be built. He was also tasked with identifying differences, creating stories and prioritizing.
3. The result. With one proxy owner always available to the team in the same time zone, we spent lot less time discussing and more time building application. Also the process of identifying differences, helped us to find non-it solutions to meet every product owner’s needs. Ultimately we got “Better software in faster”