Recently, I had the pleasure of presenting a case study webinar around a project I’ve been leading for the past 2 years: The Good, the Bad & the Ugly: A 16-Month Agile Transformation Case Study. Our audience asked a lot of great questions that I wasn’t able to address but wanted to share my answers in this blog post.

If you were able to join me, thank you! If not, I invite you to view the recording.

In your opinion, who should write user stories? The BA, Program Manager, Product Owner, or Developer?

Really, everyone can and should learn how to write a user story. Sometimes there are technical stories or non-functional stories that are best for the developer to initiate (or help refine). However, most user stories are initiated by the PO and should include the request, its business value, and the acceptance criteria (sometimes just high level). The BA can then help refine the story by identifying gaps, alternative/negative requirements or paths, dependencies, scenarios, and non-functionals. When refining the story, everyone on the team should review and provide input. Program Managers usually focus on breaking initiatives or epics into features. Once they break down features, it’s then turned over to the PO to add details.

Can you expand on what causes technical debt and how to manage it?

Technical debt is often caused by the process of breaking up work into smaller features for the purpose of demos to the PO to ensure you’re building the right thing. Over time, you might have to go back and refine or rework the code to integrate it back together or to ensure non-functional requirements (like security, usability, performance, etc.) meet the overall needs. I recommend flagging technical stories or enablers in your backlog. Ask your tech lead to make sure the developers link which user stories are dependent on which tech items. During planning sessions, try to have a balance of user stories and technical stories to ensure you have both the front end and back end components working correctly before release.

What is the role of Product Owner? Is it the same as Product Manager?

The Product Manager is strategic and forward-looking, focusing on initiatives/epics, capabilities, value streams, business drivers, and features. The Product Manager should be executing the vision of where the product is going and helping prioritize future initiatives.

The Product Owner is tactical and works with the team to design, implement, and execute. Their focus is on the current program increment (which is about 3 months of work), specifically user stories, acceptance criteria, design, deployment, user acceptance, and breaking down features. The PO is working daily with the team.

The Product Manager and the Product Owner should work closely together at the end and the start of each quarter. The PO is trusted to represent the Product Manager’s vision and be the decision maker on the design details at the team level.

How did you get around the back end systems demo?

This is an area where I’ve had teams be a little creative. If it deals with data, the team has shown the content of the before and after file. Some teams have done simulations (once, through PowerPoint animation to help illustrate a change). I’ve even had teams walk the PO through a snippet of code at a very high level to demonstrate why “cleaning up the code” made the system easier to maintain. This really depends on the goal of the code changes. However, a demo does need to be very flashy but can still help others understand the ‘value’ of doing the work.

For example, when my mechanic is explaining that I need new rotors, he draws a picture, and while I may not understand everything, it’s enough information for me to see why I need to pay them more money. Keep this in mind when you need a creative way to share valuable information with your customer (the PO).

Do you have a checklist for the Agile transitions and/or any artifacts that can help someone moving from Waterfall to Agile?

The transformation process can be very customized and specific to different environments. It can be very misleading to try to apply the same approach to every organization. We base our transitions on our Agile Transformation Roadmap. Feel free to reach out to us; we can have a conversation to further understand your current state.

We have a quick tip on transitioning from Waterfall to Agile that might give you a few recommendations to follow: How to Transition from Waterfall or Iterative to Agile. Also, a generic place to start is Scaled Agile Framework’s Implementation Roadmap.

Any recommendations to implement Agile approaches with a product requiring 90% design and configuration and only about 10% software development? Can you use scrum without a true shippable product update at the end of each sprint (for design/requirements/config work)?

Yes, I have used an agile approach very successfully for several COTS solutions. There is a lot of value in breaking up the implementation into increments, doing demos to validate your configuration decisions, and progressively building up on those decisions. Agile allowed us to discover some flaws in our configuration decisions and the time to rework them early (i.e. “learn and adjust”). Most environments are not shipping after each sprint/iteration. The objective should be to produce something of value that can be demoed. It helps set goals and see your progress toward the end goal. Even in COTS solutions, some components can be released before others. Value can be delivered early, without waiting for the final configuration and customization before the users could benefit.

Who is included in the 3 Amigos?

The organizations and agile teams I’ve worked with include the Development Team, the Scrum Master, and the Product Owner. Within the Development Team, the 3 Amigos consist of the Designer/Developer, the Tester, and the Business Analyst. The Business Analyst is aligned with the Product Owner. The Product Owner is the decision maker, and the BA helps ensure the right questions and requirements are being considered.

Question about processes. Aren’t many things we do in life a process? So why is that a bad word?

Processes are not bad in many environments, but how people use them can be. Specifically, in the software development environment, when we document a process it is often based on previous experiences and circumstances. As we move from project to project or even feature to feature, the circumstances change. It’s important to use critical thinking to make sure the previous process still applies. I’ve seen people use processes to finger point at other people, when in fact, the blame should be on processes that are no longer applicable (and potentially, a culture that didn’t empower their people to question a process). Within agile, I see different dynamics when there is a mindset that encourages relentless improvement and organic processes.

How would you evaluate soft metrics?

Questionnaires, surveys, and 360 team reviews. I try to keep them short; sometimes it’s just asking how people feel after a ceremony by getting a thumbs up or have them do a smiley face (if you are using the a Niko-Niko Calendar).

I also recommend that Scrum Masters schedule one-on-ones to help people feel safe and allow them to submit concerns without the team present. Get the session started by asking how the person would measure the team’s level of maturity in the areas of communication, honesty, trust, respect, knowledge sharing, coaching/mentoring, and transparency.

Can you point to some resources on the transformation backlog?

This was such a long answer, I decided to write a blog on it: Tasks and Tips for Developing an Agile Transformation Backlog.

What are the requirements to get training on SAFe?

The best resource for this is the Scaled Agile Framework website. We also offer the following SAFe training courses:

How did you deal with the client individuals that were resistant to the Agile transformation/new ways of working in Agile?

You must find ways to help them see the benefits and answer the question: “What’s in it for me?”.  This can be particularity hard when what you are doing now is working. However, in the long run, the world is moving and changing at such a fast pace that the old way of business is not going to hold up.  You may want to reference some of the books, blogs, and articles that talk about why companies like Blockbuster aren’t around any longer (hint: because they couldn’t change when the market and industry did). Fortunately, most industries are recognizing being agile (in some form or fashion) is a matter of long-term survival.

Have you experienced a hybrid of Waterfall and Agile as you transform?

Definitely. And in some environments, it’s justified… especially regulatory environments where certain sign offs and reviews are mandated. I like to look at each environment on a case by case basis. I think it always helps to have an outside opinion on whether your Waterfall processes are necessary or just a matter of the way you have always done it. You may be missing out on significant benefits by not challenging some of your Waterfall practices.

You mentioned PI Planning, or Quarterly Planning. In scaled scrum, who should be involved in that? The various agile teams and management? Or just one or the other?

In Scaled Agile, the Program Increment (Quarterly) Plan is considered a mandatory component of SAFe. It is described as a 2-day event that every team member and every stakeholder participates in. You can find a full description at scaledagileframework.com/pi-planning.

Can you elaborate a little more on your solution for unplanned defects/bugs and the “Do me a favor” pop ups?

Scrum Masters must be diligent about tracking unplanned work, and it needs to be transparent. I recommend creating “information radiators”. When anyone gets a request that’s not part of the plan, a “work item” sticky is created and the time spent is tracked. Use this metric to identify an unplanned work reserve when determining your velocity. If it continues to happen, the PO and Scrum Master need to determine how to contain or stop unplanned work that is impacting your ability to deliver the planned work.

Why do we need a PO and BA on a team?

POs are focused on the business need and features which we call the “happy path”. An experience BA has a lot more insight into the non-functionals, technical debt, data requirements, business requirements, and alternate and negative paths. Furthermore, the BA has tools to help capture these items visually in a light weight manner that aligns with how the technical team uses them.  BAs should also be expert facilitators that can help assist the PO in decision making and/or negotiating solutions. The key is making sure you have a BA that has formal tools and knows how to tailor them to an agile environment. For more on the specific roles, read my The Yin and Yang of the Business Analyst and Product Owner Roles blog post. We also created specialized classes to help BAs make that transition to the agile environment… just let us know and we can help!

I’m glad to hear you say that one of the 3 Amigos is a BA. Our team is planning to move to agile next year and there seems to be some confusion right now about which agile role the BA will fit into, such as Scrum Master, business owner, etc. Do you find that there is a typical role on an agile team or do you see the role still identified simply as “BA”?

There is still some confusion over the BA role on the agile team because early on there was a notation that the Product Owners and Developers could just sit and talk. However, this was 15 years ago, and we now know that these two roles are often speaking different languages (business versus technical – conceptual versus physical).

As the model of the agile team had matured, the structure that I know works is when the team consists of the “Development Team”, Product Owner and Scrum Master. The Development Team consists of the 3 Amigos – Business Analyst, Tester, and Design/Developer. I strongly advocate the BA retain the title of BA and that their skill set is a discipline just like the testers and developers.

 

I hope these answers can help you in your own agile transformation. If not, and you need more help, please let us know. There is nothing I like more than getting my hands dirty and helping teams make agile work for them! Just think, you could be my next case study!!!

– Jacqueline

Pin It on Pinterest

Share This