The sun was just peeking through the window of an almost empty level 2 at Zmart Support Centre when Amy entered the Rice room and was quickly followed by Peter.
Amy was a senior project manager. She was known for fixing projects that had gone sour and project Pink was a real lemon. Without delay, Peter got to the point: “You had a great delivery with the Stop&Shop project and I need you to get Pink back on track. You’re the third PM this project’s seen and I’m running out of time. I knew this Agile mumbo jumbo was going to end up badly. What’s wrong with PMP? That’s how we’ve always done things! Anyways, do you reckon you’re the person for the job?”
Peter was Head of Special Sales and project Pink would allow Zmart to enter a brand new market segment. He’d been trying to do that for ages. Pink was going to be big for Zmart and for Peter’s career, if he delivered the outcomes outlined in the Business Case. Otherwise, he could kiss that promotion goodbye.
Amy knew all of that too well and said: “Don’t worry Peter, I know how to make developers give their best. We’ll step up the pace and get Pink delivered on time and on budget.”
Amy had to get her head around the project very quickly and started with the documents submitted to the Approval Committee: financials, Business Case, Resourcing, the lot. SharePoint had a BRD detailing the requirements as given by the business in workshops and a detailed tech spec with several Design Decisions properly signed off by all sorts of architects. Amy recognised the developers’ names on the resource plan. They were from the vendor’s Bangalore office and got onboarded as soon as requirements were finalised.
“These are good developers,” she thought.
There was a testing plan written by the local testing team, basically saying that they were mobilised and waiting for developers to finish coding and a stack of Outlook messages signed by John Stalton - Pink’s Iteration Manager. In one of them, John talked about how work was coordinated with Bangalore on a daily basis using stand-ups. Coincidently, John arrived in the room and shortly after introductions they were talking about Pink’s problems.
“It’s impossible to get Peter’s time. I’m doing the best he can to fill in the void but we can’t waste time waiting for Peter to sign-off work. As soon as coding is done, I test and, if all works fine, I move the stories to the Done column. But I’ve just recently stopped all of that because we’re breaking existing functionality all the time. I’m always finding bugs! So I told the developers to stop doing new work for one iteration and to concentrate on making the system more stable, ” explained John.
“Good idea. When will they finish?” asked Amy.
“Two weeks tops,” said John.
“How late is the project?”, Amy probed further.
“We were on track, but Peter kept changing requirements all the time. And now, we’re late by at least a month! The previous project manager tried to talk some sense into his head… and, well, let’s say that explains why you’re here,” and John shrugged his shoulders.
“Actually it’s six weeks late, four of scope changes and two of fixes,” inferred Amy.
John just nodded a shy yes.
After the chat with John, Amy wrote an email to Bangalore introducing herself and asking for confirmation on the date they would finish the overhaul. As she typed M-A-N, to add Manish who was one of the developers, Outlook auto-completed to “Manjula Wadhwa.”
Manjula, like Amy, was a senior PM running an Agile project and it was called EPIC. Amy remembered going to one of EPIC’s Showcases and things looked good. The team was happy and on track with delivery dates. “Maybe I can do what Manjula’s doing”, thought Amy and promptly sent her an invite to talk about Pink.
The two PMs met briefly and Amy felt slightly confused afterwards. Amy kept replaying Manjula’s words in her head: “Pink shouldn’t have gone Agile. See, your team isn’t collocated and Peter can commit no time. No way that’s Agile.” Amy did retort by saying: “But there are iterations, stand-ups and story cards. That’s Agile, isn’t it?” and Manjula’s facial expression said, without words: “Not at all!”
Amy’s first action to improve Pink was a high priority email to Bangalore, and it read: “Do the bare minimum of fixes and get back to new features ASAP.” The iteration flew by and the more Amy and John tested, the more problems they found. Developers spent all of their effort in fixing bugs and made no real improvements. To make matters worse, in the last day, Peter stormed into the room with shocking news: “I just learnt that the competition is releasing a very similar solution! We must make some changes to ensure Zmart’s got the edge,” blurted Peter.
Amy mustered her courage and said: “The system is unstable, we need to fix its foundations before any new changes happen or features are added.”
“How long are we talking about here?” asked Peter.
Amy had no idea and called John. He looked into spreadsheets and winged: “Another iteration should do.”
“How can that be?” said Amy. “We found hundreds of bugs and haven’t even fixed the original problems, how can it only be two weeks?” she continued.
“Here, check this out, if Bangalore work some late hours and weekends we can still catch up”, John explained.
Amy wasn’t sure. Maybe it was possible. She wanted it to be possible. It had to be! And shortly after another go-even-harder themed email arrived in Bangalore.
Another iteration went by and many bugs got fixed - the system seemed slightly more stable and the team charged towards the new features Peter had asked for. “The backlog still looks full, there’s no way we’re going to be able to finish it all,” says Amy to John who agreed and suggested adding some more developers and reducing the amount of testing that he and Amy were doing. “The testing team will check things when we’re done anyways”, John explained. And with this strategy the team suddenly sprung into incredible speed.
Over the last month the Done column grew cobwebs. The extra developers changed that and stories were quickly finding their way to the east side of the Kanban. Amy still tested here and there, just to make sure things were OK. This routine repeated itself for another two iterations and at the end, 90% of the backlog had moved across the wall.
The time to move code into QA finally came. John and Amy paired to plan the deployment activities across infrastructure, the testing team and Bangalore. Estimated effort: two point five days exactly.
A week later Amy’s iPhone email notification chimed. It was the testing team. “Amy, we regret to inform but Pink didn’t pass smoke testing. The infrastructure guys concluded that one of RTS’ interfaces has changed and Pink is still using the old version. You must get Pink up to speed with the new API before any testing takes place. Please keep in mind that the testing environment is fully booked until the end of the quarter.”
“WTF!! How come no one told us that this f@#$# interface changed?!” shouted Amy despairingly at her iPhone.
Bangalore and the EAI team got together to discuss the API upgrade. The conclusion was everything Amy didn’t want to hear and meant redesigning half of what they had already finished. Before QA Pink was only late but now it was simply out of control.
Amy knew she had to tell Peter about what happened. Pink wasn’t going to be delivered on time. Failure was not a word in Amy’s dictionary but this new way of working was simply too chaotic and feeling that she was out of her depth was unavoidable.
Once more Amy promised Peter a rescue plan and once more Manjula crossed her mind. “I’ll see if she can help me with this new plan,” pondered Amy. Manjula was happy to try and help because, as a matter of fact, she had already heard about the QA debacle.
“Amy, your team is Fragile, not Agile. If you want to change it, some big steps must be taken,” started Manjula.
“I’m all ears,” replied Amy.
“Pink started the wrong way. It should have never been an Agile project to begin with. The team isn’t physically co-located in the same room and Peter never committed to be part of the team. These two points alone are enough to not run Agile. Also, John keeps on creating stories as he sees fit, estimates them and decides when they’re Done. Bangalore is always overcommitted and, understandably, frustrated. Worst of all, testing is an afterthought. In Agile testing must be an integral part of every iteration, not a separate phase done by another group in isolation,” continued Manjula.
“Yeah, but...” Amy tried to interject.
“There’s more, there’s more,” said Manjula, and continued: ”Continuous Integration running regression tests is non-existent. The last deployment to QA clearly showed that Pink’s dependencies have no tests! How can you be sure any integration point works without tests? You see Amy, delaying integration may seem like a good idea at first because it feels like the team is moving faster, but it’s actually a huge risk. Early testing is key because it alerts the team when changes happen.”
When Amy realised Manjula wasn’t going to stop, she opened a spreadsheet on her laptop and turned it to her. It was Pink’s backlog.
“Wow! That’s a lot of stuff to do! How many points can you do per iteration?” asked Manjula.
“20 points, but we’re getting better. I’m consistently giving the team a stretch goal of 30. How many points does your team do per iteration?” asked Amy.
“12. But that doesn’t really matter. My points are different than yours. More points don’t immediately mean higher productivity because velocity is a mere progress metric. You shouldn’t use it as a target, let alone a stretch one. Overcommitted teams quickly get demotivated and produce even less,” explained Manjula.
“I don’t really know what to say Manjula. With all the meetings and cards I really thought Pink was Agile. I guess it’s Agile only on the surface. It’s like an Agile veneer,” lamented Amy.
“Yep and if you want to deliver anything at all, your need needs to implement CI and build some level of automated testing. You’ll need to make time for these to happen. And there’s only two ways to make up time in a project …” Manjula stared at Amy.
“... massive de-scoping or pushing dates out, I know. Peter won't be happy with either of the options. On top of that, I don’t even have an environment to test anymore.” finished Amy.
“Get your team together in a room and let them devise a plan,” said Manjula. “The people doing the work are the only ones who can actually estimate effort and commit to work. I suspect you’ll need to reset your project and figure out better ways of organising the team,” then Manjula got up, walked towards a white board, scribbled something and politely left the room wishing Amy the best of luck with trying and transforming Pink into a truly Agile project.
Amy got up and took a photo of the white board, which read:
It was hot and dark outside when Amy arrived home. A glass of red was the perfect company for career musing. She rehearsed all the things she was going to tell Peter the next day and booked “the” meeting. The invitation’s subject read: “Moving Pink from Fragile to Agile”. Amy hit send and went to her kids' room, still hoping to spend some quality time with them. They were long asleep.
Amy kickstarted the meeting with Pink’s burn-up chart. It had two lines, one with the cumulative number of points delivered so far and a second one with the total number points representing the entire backlog. The two clearly didn’t cross at the desired date, actually they didn’t cross at all!
“Our only chance to deliver Pink is to fix the underlying technical practices and issues and cut back to the minimum number of features. With this approach, even though “incomplete”, some value can be realised and maybe, with the extra revenue flowing in we could justify extending the team to deliver more features in the future,” explained Amy.
“You’re telling me that it’s either this or we run out of funds and nothing gets delivered?” asked Peter.
Amy nodded positively.
“This is our last go at it. If we fail, the project will be canned and we’ll be on the Director’s bad books for a long time. What are you thinking exactly?” queried Peter.
“We hire a full time tester and bring the Bangalore devs here. Then, we run a series of focused workshops, similar to a mini-inception. The idea is to define three things: our minimum viable product - MVP, continuous integration implementation strategy and critical test coverage. Your presence Peter, in all workshops, is crucial,” said Amy.
“Are you kidding me! I have no time as is and you want me to be there full time?” bursted Peter.
“Precisely. Think about it Peter, we haven’t go much so far. Every time we need your input it takes days. We need to move fast and there’s no time for email threads and phone tag. We need you there to make decisions on the spot, inspire the team and keep us real,” explained Amy.
“I guess you’re right. Every time I see the results I feel like if I had spoken with the devs I could explain better what I wanted. OK. I’ll do my best, but there’s a condition - I need an immovable delivery date,” completed Peter.
This MVP inception was fundamental. Amy hired a couple of Agile facilitators to help out driving the workshops and a couple of days later the MVP backlog came to life. Estimates, this time, were given by developers and testers and the release plan was based on the team’s true velocity. It was a plan the team was happy to stand behind and commit to.
Implementing critical automated tests and continuous integration were the first steps undertaken by the team. It wasn’t easy but having these in place created a safety net for the team. This net allowed for changes to be made safely and their confidence rose. The team kept moving forward, always developing tests before the implementation. Pace was sustainable and predictable and Peter no longer wondered what was happening with the project. He now knew it. He’d spent at least three hours daily in the project room and eventual changes to stories took place on the spot, as developers implemented them, safeguarding the deadline.
Pink MVP went live as planned and Peter now believes his team’s capacity to follow through with commitments. He now believes because he was there, present in the room, he shared and influenced the decisive moments that made Pink MVP possible.
The sun is just peeking through the window of an almost empty level 2 at Zmart Support Centre on the day after go live. Amy is sitting in the Rice room when she feels a light tap on shoulder and hears: “Well done Amy. Tell me, what comes after MVP?” asks Peter with a broad grin on his face.
Amy was a senior project manager. She was known for fixing projects that had gone sour and project Pink was a real lemon. Without delay, Peter got to the point: “You had a great delivery with the Stop&Shop project and I need you to get Pink back on track. You’re the third PM this project’s seen and I’m running out of time. I knew this Agile mumbo jumbo was going to end up badly. What’s wrong with PMP? That’s how we’ve always done things! Anyways, do you reckon you’re the person for the job?”
Peter was Head of Special Sales and project Pink would allow Zmart to enter a brand new market segment. He’d been trying to do that for ages. Pink was going to be big for Zmart and for Peter’s career, if he delivered the outcomes outlined in the Business Case. Otherwise, he could kiss that promotion goodbye.
Amy knew all of that too well and said: “Don’t worry Peter, I know how to make developers give their best. We’ll step up the pace and get Pink delivered on time and on budget.”
Amy had to get her head around the project very quickly and started with the documents submitted to the Approval Committee: financials, Business Case, Resourcing, the lot. SharePoint had a BRD detailing the requirements as given by the business in workshops and a detailed tech spec with several Design Decisions properly signed off by all sorts of architects. Amy recognised the developers’ names on the resource plan. They were from the vendor’s Bangalore office and got onboarded as soon as requirements were finalised.
“These are good developers,” she thought.
There was a testing plan written by the local testing team, basically saying that they were mobilised and waiting for developers to finish coding and a stack of Outlook messages signed by John Stalton - Pink’s Iteration Manager. In one of them, John talked about how work was coordinated with Bangalore on a daily basis using stand-ups. Coincidently, John arrived in the room and shortly after introductions they were talking about Pink’s problems.
“It’s impossible to get Peter’s time. I’m doing the best he can to fill in the void but we can’t waste time waiting for Peter to sign-off work. As soon as coding is done, I test and, if all works fine, I move the stories to the Done column. But I’ve just recently stopped all of that because we’re breaking existing functionality all the time. I’m always finding bugs! So I told the developers to stop doing new work for one iteration and to concentrate on making the system more stable, ” explained John.
“Good idea. When will they finish?” asked Amy.
“Two weeks tops,” said John.
“How late is the project?”, Amy probed further.
“We were on track, but Peter kept changing requirements all the time. And now, we’re late by at least a month! The previous project manager tried to talk some sense into his head… and, well, let’s say that explains why you’re here,” and John shrugged his shoulders.
“Actually it’s six weeks late, four of scope changes and two of fixes,” inferred Amy.
John just nodded a shy yes.
After the chat with John, Amy wrote an email to Bangalore introducing herself and asking for confirmation on the date they would finish the overhaul. As she typed M-A-N, to add Manish who was one of the developers, Outlook auto-completed to “Manjula Wadhwa.”
Manjula, like Amy, was a senior PM running an Agile project and it was called EPIC. Amy remembered going to one of EPIC’s Showcases and things looked good. The team was happy and on track with delivery dates. “Maybe I can do what Manjula’s doing”, thought Amy and promptly sent her an invite to talk about Pink.
The two PMs met briefly and Amy felt slightly confused afterwards. Amy kept replaying Manjula’s words in her head: “Pink shouldn’t have gone Agile. See, your team isn’t collocated and Peter can commit no time. No way that’s Agile.” Amy did retort by saying: “But there are iterations, stand-ups and story cards. That’s Agile, isn’t it?” and Manjula’s facial expression said, without words: “Not at all!”
Amy’s first action to improve Pink was a high priority email to Bangalore, and it read: “Do the bare minimum of fixes and get back to new features ASAP.” The iteration flew by and the more Amy and John tested, the more problems they found. Developers spent all of their effort in fixing bugs and made no real improvements. To make matters worse, in the last day, Peter stormed into the room with shocking news: “I just learnt that the competition is releasing a very similar solution! We must make some changes to ensure Zmart’s got the edge,” blurted Peter.
Amy mustered her courage and said: “The system is unstable, we need to fix its foundations before any new changes happen or features are added.”
“How long are we talking about here?” asked Peter.
Amy had no idea and called John. He looked into spreadsheets and winged: “Another iteration should do.”
“How can that be?” said Amy. “We found hundreds of bugs and haven’t even fixed the original problems, how can it only be two weeks?” she continued.
“Here, check this out, if Bangalore work some late hours and weekends we can still catch up”, John explained.
Amy wasn’t sure. Maybe it was possible. She wanted it to be possible. It had to be! And shortly after another go-even-harder themed email arrived in Bangalore.
Another iteration went by and many bugs got fixed - the system seemed slightly more stable and the team charged towards the new features Peter had asked for. “The backlog still looks full, there’s no way we’re going to be able to finish it all,” says Amy to John who agreed and suggested adding some more developers and reducing the amount of testing that he and Amy were doing. “The testing team will check things when we’re done anyways”, John explained. And with this strategy the team suddenly sprung into incredible speed.
Over the last month the Done column grew cobwebs. The extra developers changed that and stories were quickly finding their way to the east side of the Kanban. Amy still tested here and there, just to make sure things were OK. This routine repeated itself for another two iterations and at the end, 90% of the backlog had moved across the wall.
The time to move code into QA finally came. John and Amy paired to plan the deployment activities across infrastructure, the testing team and Bangalore. Estimated effort: two point five days exactly.
A week later Amy’s iPhone email notification chimed. It was the testing team. “Amy, we regret to inform but Pink didn’t pass smoke testing. The infrastructure guys concluded that one of RTS’ interfaces has changed and Pink is still using the old version. You must get Pink up to speed with the new API before any testing takes place. Please keep in mind that the testing environment is fully booked until the end of the quarter.”
“WTF!! How come no one told us that this f@#$# interface changed?!” shouted Amy despairingly at her iPhone.
Bangalore and the EAI team got together to discuss the API upgrade. The conclusion was everything Amy didn’t want to hear and meant redesigning half of what they had already finished. Before QA Pink was only late but now it was simply out of control.
Amy knew she had to tell Peter about what happened. Pink wasn’t going to be delivered on time. Failure was not a word in Amy’s dictionary but this new way of working was simply too chaotic and feeling that she was out of her depth was unavoidable.
Once more Amy promised Peter a rescue plan and once more Manjula crossed her mind. “I’ll see if she can help me with this new plan,” pondered Amy. Manjula was happy to try and help because, as a matter of fact, she had already heard about the QA debacle.
“Amy, your team is Fragile, not Agile. If you want to change it, some big steps must be taken,” started Manjula.
“I’m all ears,” replied Amy.
“Pink started the wrong way. It should have never been an Agile project to begin with. The team isn’t physically co-located in the same room and Peter never committed to be part of the team. These two points alone are enough to not run Agile. Also, John keeps on creating stories as he sees fit, estimates them and decides when they’re Done. Bangalore is always overcommitted and, understandably, frustrated. Worst of all, testing is an afterthought. In Agile testing must be an integral part of every iteration, not a separate phase done by another group in isolation,” continued Manjula.
“Yeah, but...” Amy tried to interject.
“There’s more, there’s more,” said Manjula, and continued: ”Continuous Integration running regression tests is non-existent. The last deployment to QA clearly showed that Pink’s dependencies have no tests! How can you be sure any integration point works without tests? You see Amy, delaying integration may seem like a good idea at first because it feels like the team is moving faster, but it’s actually a huge risk. Early testing is key because it alerts the team when changes happen.”
When Amy realised Manjula wasn’t going to stop, she opened a spreadsheet on her laptop and turned it to her. It was Pink’s backlog.
“Wow! That’s a lot of stuff to do! How many points can you do per iteration?” asked Manjula.
“20 points, but we’re getting better. I’m consistently giving the team a stretch goal of 30. How many points does your team do per iteration?” asked Amy.
“12. But that doesn’t really matter. My points are different than yours. More points don’t immediately mean higher productivity because velocity is a mere progress metric. You shouldn’t use it as a target, let alone a stretch one. Overcommitted teams quickly get demotivated and produce even less,” explained Manjula.
“I don’t really know what to say Manjula. With all the meetings and cards I really thought Pink was Agile. I guess it’s Agile only on the surface. It’s like an Agile veneer,” lamented Amy.
“Yep and if you want to deliver anything at all, your need needs to implement CI and build some level of automated testing. You’ll need to make time for these to happen. And there’s only two ways to make up time in a project …” Manjula stared at Amy.
“... massive de-scoping or pushing dates out, I know. Peter won't be happy with either of the options. On top of that, I don’t even have an environment to test anymore.” finished Amy.
“Get your team together in a room and let them devise a plan,” said Manjula. “The people doing the work are the only ones who can actually estimate effort and commit to work. I suspect you’ll need to reset your project and figure out better ways of organising the team,” then Manjula got up, walked towards a white board, scribbled something and politely left the room wishing Amy the best of luck with trying and transforming Pink into a truly Agile project.
Amy got up and took a photo of the white board, which read:
- No co-location -> no Agile
- No business commitment -> no Agile
- No full time testing from offset -> no Agile
- Implement Continuous Integration (regression and interface integration included)
- The team decides what Done means
- Keep a sustainable pace, overtime isn’t manageable
- Velocity isn’t a target, use it to plan and communicate progress
- The team commits to the work. Managers don’t distribute stories and tasks
It was hot and dark outside when Amy arrived home. A glass of red was the perfect company for career musing. She rehearsed all the things she was going to tell Peter the next day and booked “the” meeting. The invitation’s subject read: “Moving Pink from Fragile to Agile”. Amy hit send and went to her kids' room, still hoping to spend some quality time with them. They were long asleep.
Amy kickstarted the meeting with Pink’s burn-up chart. It had two lines, one with the cumulative number of points delivered so far and a second one with the total number points representing the entire backlog. The two clearly didn’t cross at the desired date, actually they didn’t cross at all!
“Our only chance to deliver Pink is to fix the underlying technical practices and issues and cut back to the minimum number of features. With this approach, even though “incomplete”, some value can be realised and maybe, with the extra revenue flowing in we could justify extending the team to deliver more features in the future,” explained Amy.
“You’re telling me that it’s either this or we run out of funds and nothing gets delivered?” asked Peter.
Amy nodded positively.
“This is our last go at it. If we fail, the project will be canned and we’ll be on the Director’s bad books for a long time. What are you thinking exactly?” queried Peter.
“We hire a full time tester and bring the Bangalore devs here. Then, we run a series of focused workshops, similar to a mini-inception. The idea is to define three things: our minimum viable product - MVP, continuous integration implementation strategy and critical test coverage. Your presence Peter, in all workshops, is crucial,” said Amy.
“Are you kidding me! I have no time as is and you want me to be there full time?” bursted Peter.
“Precisely. Think about it Peter, we haven’t go much so far. Every time we need your input it takes days. We need to move fast and there’s no time for email threads and phone tag. We need you there to make decisions on the spot, inspire the team and keep us real,” explained Amy.
“I guess you’re right. Every time I see the results I feel like if I had spoken with the devs I could explain better what I wanted. OK. I’ll do my best, but there’s a condition - I need an immovable delivery date,” completed Peter.
This MVP inception was fundamental. Amy hired a couple of Agile facilitators to help out driving the workshops and a couple of days later the MVP backlog came to life. Estimates, this time, were given by developers and testers and the release plan was based on the team’s true velocity. It was a plan the team was happy to stand behind and commit to.
Implementing critical automated tests and continuous integration were the first steps undertaken by the team. It wasn’t easy but having these in place created a safety net for the team. This net allowed for changes to be made safely and their confidence rose. The team kept moving forward, always developing tests before the implementation. Pace was sustainable and predictable and Peter no longer wondered what was happening with the project. He now knew it. He’d spent at least three hours daily in the project room and eventual changes to stories took place on the spot, as developers implemented them, safeguarding the deadline.
Pink MVP went live as planned and Peter now believes his team’s capacity to follow through with commitments. He now believes because he was there, present in the room, he shared and influenced the decisive moments that made Pink MVP possible.
The sun is just peeking through the window of an almost empty level 2 at Zmart Support Centre on the day after go live. Amy is sitting in the Rice room when she feels a light tap on shoulder and hears: “Well done Amy. Tell me, what comes after MVP?” asks Peter with a broad grin on his face.
No comments:
Post a Comment