The Tale of Two Agile Journeys (Part 2)
Joy was really excited to start a new adventure with a new company as a Senior Project Manager. She has been a change agent through her career and really wanted to make a difference wherever she goes. The new gig was no different.
Joy’s first week went really well. Everyone was friendly, welcoming and ready to make things happen. Her schedule started to fill up as the weeks went by and she picked up a couple of small projects as well as a high visibility project. She started by setting up sometime with the business to understand the scope of the project then went on to craft a proposal on acquiring a software development vendor to help with the new project but since there was not enough budget, she really couldn’t get external help and had to magically find it internally.
It took Joy about 3 months just to get a team together but wait she thought, was it really a team? It was only her and Adam, a Business Analyst who helped with conducting interviews with the different business stakeholders and “gathering” the requirements. Three months went by and the requirements were “ready” for the developers to start.
Joy found herself negotiating with the development managers to find at least 2 developers who can start working on her project. Since it was a high visibility project, she really didn’t have to do much negotiating. The CIO and PMO director stepped in to secure the developers “time” needed to work on the project. While the developers did start, that didn’t mean that other projects they were already working on went away. It just got added to their already full plate. They just needed to work faster. Well, after 6 months of development, the project was finally “ready” for testing.
Same story yet again, Joy had to convince the QA manager that her Project is already late and she needs testers to get started as soon as possible. Finally, 2 members from the QA team started to test the code. As you might expect, a lot of fireworks were taking place. No, not the ones for celebration. Those were mainly the sheer number of bugs the QA team was finding. Now developers who knew the code were on new projects but had to find time (or overtime to be accurate) to fix the bugs found by the QA team.
Here comes the BIG boom
You might be thinking that the story has ended there but that was just half of the story. Finally after 3 months of “gathering” requirements, 6 months of development and 3 months of testing (a total of 12 months/ 1 FULL year) and a lot of heartache came the BIG boom. It’s time to finally deploy the new work into production. Well, deployment had to go according to “plan” and off it went. I don’t have to tell you what happened but I will anyway. Customers complains went through the roof and the poor operations and production support teams had to work day and night to fix all the problems the BIG bang deployment has caused.
New way of thinking
Joy knew that this wasn’t the way to work. It was just too cumbersome and not really fulfilling or fun. She thought to herself that her company could really benefit from Agile practices she has used on different projects. She started socializing the idea with her peers but there wasn’t much traction there. Everyone was so busy that every time they setup a time to meet, something comes up and she ends up cancelling the meeting. She then tried to host some lunch and learn sessions and invited different speakers to speak about their journey to adopting agile but while the interest was high in the beginning (especially with food and refreshments being offered), it started fading away after a couple of months.
Joy was finally able to convince one of the IT directors to use agile on her upcoming project. Also, she had a Subject Matter Expert (SME) who played the role of a Product Owner (PO). She started slowly and worked with the Business Analyst to write user stories.
While it wasn’t ideal that developers and testers weren’t there from the start, she was able to bring them early in the process to get their feedback. She even started having a daily standup and invited the “team” including the Business Analyst, Developers and Testers. Initially there was some resistance from team but she requested that they try it for a month and raise any concerns if they don’t like the process (essentially a retrospective). After a month into it, the team started getting into a rhythm and liked it a lot. The conversations were just so rich and bringing different perspectives to the table made the team and the product better.
After sometime, the team started doing monthly demos with the business stakeholders to get their feedback. It was a wonderful experience and the team felt that they were improving as they went and started gaining insights into each other work. Empathy installed.
Now with the results from the project under her belt, Joy started sharing with the PMO director, IT directors and the CIO who were really encouraged by the results and most of all the business feedback.
Talking the talk but not walking the walk
While leaders were encouraged, they continued to ask for the same reports and management continued to conduct the same performance reviews based on individual goals. The excitement rush Joy felt from helping her team grow and making her customers happy soon waned. She was not able to make a difference which is her biggest motivator. Joy later moved on to a different adventure with the same excitement to make a difference again.
The Biggest Lessons
Joy started with awareness which is usually a good place to start. She also had experience with running agile projects and she understood very well the business needs and IT delivery cycle as well as the importance of faster feedback loops. She did learn however that even though awareness and results are important, leadership and management need to support the new behaviors and way of thinking otherwise, the results will be short lived and not sustainable.
Note: This is based on a true story however events and characters have been changed to protect the innocent. To read Part 1, click here.
