originally published by Brent Harrison, Founder & President of SmokeJumper Strategy
featuring Cory Morgan, Solution Architect at Axian
I recently worked with a leading online retailer and wanted to share one product team’s agile journey. First the “players”:
- Margaret is the Tech Lead for the team that is focused on marshalling and delivering digital content across a variety of platforms (web, mobile) in support of merchandising, social interaction and ecommerce.
- Cory is the Business Systems Analyst and serves as the team’s “Agile Product Owner”.
- Elizabeth is a Senior Project Manager and serves as the team’s Scrummaster.
- And I, Brent Harrison, am Founder & President of SmokeJumper Strategy and a former executive at Apple, AOL and Netscape. As an Agile Coach, I have supported dozens of software development teams undertake transitions to Agile.
I recently sat down with Cory, Elizabeth and Margaret to chat with them about their experiences applying Agile as a product and project planning and management method.
What does “Agile” mean to you? How does it benefit your company?
Margaret: I think “adaptive” when I think of the Agile process. Unlike the waterfall or more traditional methodologies, Agile, and the iterative nature of the process, allows teams to respond to change much more easily. With change often being the only constant in a very chaotic environment, teams can turn on a dime faster and with fewer repercussions than the traditional development.”
Elizabeth: “To me, Agile means to continuously and iteratively deliver software to the business stakeholder; and to be open to — and even WELCOME — *change* as part of the process. You learn as you go. You grow as you learn. You improve as you grow. And you do this all in two-week cycles. There is a process that is followed (including sprint planning and daily stand-ups or “scrums”) to get to the end result = deliverable, demo-able code after each iteration. The team gathers briefly each day to discuss progress, remove impediments and motivate each other. At the end of two weeks, you evaluate what went well and what could be improved. Then you do it all over again. It’s FUN!”
What does it take to be successful in working in Agile?
Margaret: “I think Agile only works when everyone on the team is on board. Agile isn’t so much a process as it is a mindset or an attitude on how to take on a project. Agile can take away the “time-sucks” and allow teams to have frequent sanity checks, but it takes the whole team to make sure time and energy isn’t being spent on noise.”
Cory: “From afar, especially coming from a waterfall SDLC point-of-view, Agile may appear to be much “looser” approach to developing software. In reality, strict adherence to the principles, processes and practices of Agile are what make it most successful. All involved parties, from the delivery team to the business stakeholders and everyone in between, must be committed to their role in the process. And for success here, one must be prepared on a daily basis to expect change; I may have worked extremely hard on something yesterday, but today is a new day and we must be prepared to evolve immediately.”
- A dedicated team (meaning not a lot of turnover)
- A good Agile tool (backlogs, story boards, burndown charts)
- Team buy-in and commitment to the Agile process in general
- Clear roles and responsibilities
- Dedicated Scrum Master and Product Owner
- Make it fun
- Solid definition of done
- Daily scrums – don’t miss them
- Face-to-face interaction
- Embrace simplicity
Brent: “Based on Margaret, Cory and Elizabeth’s responses to this question, it is clear that they understand that Agile is a “contact sport”. On the surface Agile often appears simplistic and lacking rigor – but, paradoxically, it takes effort and practice in order to refine and apply Agile effectively.”
How do you track progress?
Elizabeth: “Burndown Charts and Task Boards that are reviewed at daily scrum meetings. I love burndown charts – I am a burndown chart geek! ”
Brent: “For more information about tracking progress, see my blog post: The Three Most Important Metrics for Agile Teams
What’s been the biggest challenge for you and your teams?
Margaret: “We’re still improving our ability to precisely determine the amount of time a particular feature or functionality will take to complete. Part of the challenge is understanding if the work is completely defined and if we truly have all the requirements needed for beginning and completing the work. Often we find delays mid-sprint because we might be scrambling to retrieve a visual we missed in sprint planning or clearing up an assumption that had to be made in order to continue with the work.”
Elizabeth: “Team consistency, meaning we tend to lose people and bring new people on fairly frequently. This is pretty much the lay of the land, and so we adapt to it, but with every team member change it has an impact on team unity, communication and velocity.”
Brent: “There is much that goes into being successful with Agile. Margaret and Elizabeth raise good points. Leadership understanding and support is critical. Commitment to dedicated and persistent teams is key. The rest takes discipline and practice as well as a continuous team commitment to “inspect and adapt” — how to define, develop and test their product as well as how they work together.”
What are the benefits you’ve experienced in going Agile?
Cory: “Even though we’ve been working in Agile for some time, we’ve recognized some significant benefits since our formal Agile training a few months back. In essence, our team is much more comfortable making commitments and delivering on time. We can now rely on our team velocity to plan appropriately. We can now delivery stories faster to QA during a sprint. We adjust much better to changing expectations during a sprint. We can track our progress much more clearly, and have fewer surprises during sprint demos.”
Brent: “Forrester did some seminal research on Agile projects across many organizations. They identified five (5) leading benefits of Agile:
- Reduced time-to-market
- Increased quality
- Reduced waste
- Better predictability
- Better morale.”
How did you (and your teams) develop the skills and knowledge to start doing Agile?
Cory: “I developed my Agile skills on a project previous to joining my current team, where I learned from a very experience scrum master. Most “Agile” teams that I’ve engaged with or talked to start with “some type of iterative development” and build from there. Our team initially brought together the collective experience of each member, and with the desire to the continually grow, sought ways to improve our Agile practice. Brent then took our foundation, along with our eagerness to grow, and helped formalize and improve many aspects of our process.”
Elizabeth: “We enlisted Brent’s help to do Agile Coaching with the whole team. I think this was essential and this is where we really started to gel as a team. We had been Agile/Scrum before that, but it was great to get team buy-in on things like roles and responsibilities, what Agile REALLY means, and why it’s essential to hold a daily scrum, etc. It was also great come to a common team-wide agreement on things like definition-of-done and team working agreements.”
Brent: “Because Agile places emphasis upon a team for delivery, it is important that the team takes the time to make commitments around how they want to work and that they review and revise those commitments over time. Often times a team workshop combined with embedded coaching can help jump-start the learning process and team performance as Cory and Elizabeth note.”
What’s your favorite Agile technique or planning ceremony? Why?
Margaret: “I really like the demos. It not only shows tangible progress of what the team has done in the 2-week sprint, but it also gives stake holders a chance to provide feedback and course correction (if necessary) throughout the project, not just at the end when it’s often too late to change anything. Also, we because we stress that the work be as close to production-ready as possible, the feedback we get is much more relevant.”
Elizabeth: “The Sprint Retrospective. We look back over the past sprint and everyone on the team contributes to what went well, what didn’t, and what we could change. We do it by handing out sticky notes to everyone and putting the ideas up on the wall. We then vote on what changes to commit to the following sprint. It’s interactive, everyone is involved, everyone has a voice, we get to celebrate progress and it’s just an all around good time! Sometimes there’s even a little drama!”
Brent: “One of the important principles of Agile is for teams to continually “inspect & adapt” their progress as they go. The demo Margaret refers to is a great place to inspect & adapt the product the team is building. And the retrospective, which Elizabeth is fond of (and great at facilitating by the way), is the place where the team can inspect & adapt the process and ways they want to work together.
Cory: “I really enjoyed our rapid-fire estimation session the other day to size our backlog in preparation for release planning. It was much better than sitting in a room, staring at a computer screen, clicking through JIRA tickets one by one, with me doing most of the talking. The team was really engaged, and think we’ll look forward to estimating in the future, which can be an arduous and often dreaded task.”
Brent: “Strange as it sounds, I’m fascinating by estimation and estimation techniques. As teams move from being able to deliver reliably sprint-by-sprint, it becomes easier for them to take their estimation skills and apply them to a longer time horizon (e.g. many sprints or releases into the future). This allows for better alignment with business stakeholders and a clearer picture of what can be delivered when.”