Agile Leadership Webinar Q&A-EN

I often find that while agile is implemented at the team level, the rest of the organization doesn’t change. For agile to be successful, the entire organization needs to adjust their mindset. In my recent webinar, Selling Leadership on More than the Idea of Agile, I shared strategies and recommendations to sell leadership on the realities of an agile environment and how their buy-in and support is required to make it work! 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.

Can you define lean requirements?

This is definitely an “it depends” answer, but for most teams it starts by focusing on the “what” they are trying to accomplish and the associated business value. Then defer the “how” and the design discussions until the sprint starts. Before the sprint, you just need to know enough to be able to estimate what it will take to deliver “what” they want.

Lean requirements sound great. Collaboration does too. My concern is that the detailed documentation may be needed years later.

I recommend that as you work the items in your backlog, you somehow capture and document the outcome in a lean and maintainable way. This is very different than doing detailed requirements up front. However, it will help having to update the documentation when requirements change during a project. How many times has your documentation become obsolete at the end of a project because trying to maintain it ‘in action’ was too cumbersome? Capture what you need and in a format that makes it useful and adaptable.

For large organizations that are used to receiving status and metrics on projects a certain way. How do agile teams continue to show progress and effectiveness that satisfy the needs of senior managers?

For a while you may have to show managers the traditional and agile metrics in parallel. However, have a plan to eventually convert them to only seeing the metrics that show what’s important on an agile project. For example:

• The team is “delivering value” not “delivering code and story points”
• The team has reduced bugs by showing the new feature delivery instead of the counting bugs fixed.
• I recommend having a baseline of how long a project would take and how much it would cost if we delivered everything in a waterfall format. Then show them how quickly the team can deliver something of value by eliminating requirements instead of making sure every requirement is met.
• For more on agile metrics, see my 2-part blog series: Do Your Agile Project Metrics Measure Up? Why Traditional KPIs Won’t Work and Start Measuring Success With These 5 Agile KPIs.

It seems like our leadership likes to use agile words but doesn’t really care for agile principles. It is very hard to break through that veneer of “agile” to make actual progress. Is there anything teams can do in that environment to maintain what they know they should be doing?

Here are a few things I’ve seen that help change superficial perception of agile:

1. Get leadership to start realizing that there is a difference between “doing agile” and “being agile”. To really benefit, there has to be a mind shift and culture change that starts from the top down.
2. Share the concept of an agile maturity model with them. Be sure to emphasize that if you don’t start at level 1, you will never really get the full benefit.
3. Don’t underestimate the value of having agile coaches. Also, be aware that if you are not maturing with a certain coach, maybe you need a different one. I compare this to a personal trainer – you need someone to push you and sometimes pull you to overcome your bad habits.

Management won’t buy it if it’s not about fast in my organization.

That’s typically when someone is looking for a magic bullet. They can keep looking because there aren’t any magic bullets and agile definitely isn’t one. Pushing people to simply work faster typically results in burn out or poor quality – and because high performers don’t like doing sloppy work so often, their best option is to leave the company (in my experience). Management can want and wish for faster, but hopefully they don’t do too much damage before they figure out that faster isn’t always better.

We have been told, when pushing back for a mid-sprint change, “I’m the COO, and that’s my right.”

Upper management is one of the biggest violators of the few agile boundaries that exist. When I’m coaching, I help Scrum Masters find a way to capture the impact of these mid-sprint changes. Transformation retrospectives with leadership are a great opportunity to help get these sensitive issues out in the open for discussion.

On one project, we showed the management team a presentation on what we called “death by the thousand cuts”. What this leadership team (of about 10 people), didn’t take into account was that everyone on the leadership team was breaking the rule… so in the course of one quarter, 10 x 3 or 4 exceptions turned into 30 – 40 disruptions to the work that they themselves had prioritized and helped plan. It was a little embarrassing but also extremely eye-opening.

My organization has initiated an Agile/DevOps approach for a large multi-year project (several years underway) with development being brought in house. What challenges do you expect with this (large project – years underway/years from being complete)? Both with leadership and in expanding development operations.

The key is to treat the implementation itself as an agile project: break it up and then identify the priority, value, and amount of effort for each item. Look at it as a continuous process improvement and not just one specific destination. This can help get everyone in the mindset that it’s not a race. If it feels like a race, you are just setting yourself up to get discouraged. However, this isn’t to say that you don’t need goals and objectives; just be sure to base them on incremental KPIs. Also, make sure to celebrate the wins along the way! Please contact us if you would like to dive deeper into your scenario and discuss how we can help.

Is the “Transformation Scrum” a one-time event where you come out with the lessons learned and from there do “Mature Scrums”?

A typical Transformation Scrum for SAFe keeps a regular cadence for 2-3 years. Even after this, I recommend doing quarterly maintenance retrospectives on how things are going. I definitely encourage mature scrums to do a retrospective in the spirit of agile continuous improvement. The teams are always improving. The purpose of a transformation scrum is to help the executive and corporate environment improve to better support an Agile culture. Plus, even mature scrums fall back into bad habits and can always use a little reflection and improvement tune-up.

At what point do you communicate to leadership that Agile requires them to transform as well as the teams?

As soon as they say they support Agile. Be sure you are on the same page by asking them what Agile means to them and their expectations. On the other hand, if you are already well into an agile transformation and leadership feels like they aren’t seeing results they wanted, I recommend having a “talk” to revisit their original expectations.

Can you give some examples of backlog items for the transformation Scrum?

1. Soft Skills Training
2. Team Working Agreements Workshop
3. Executive Working Agreements Workshop
4. Portfolio/Discovery Kanban Board Creation
5. Scrum of Scrum Meeting Kick-Off
6. Team Building Workshop
7. Guild/Community of Practice/Community of Interest Kick-Off
8. Agile Team Spirit Week
9. Cross Functional Training Schedule
10. 360 Team Reviews
11. Executive Agile Orientation
12. Transformation Retrospective
13. Open Space Day for Agile Topics
14. Scrum Master Retreat
15. Soft Skills Curriculum Roll out
16. KPI, Velocity, and Capacity Workshop

I think a lot of organizations look to Agile to solve all their problems, but without doing any root cause analysis on why the waterfall process wasn’t working.

Great point. As a coach/business analyst hybrid, I immediately want to look at the AS IS and intended TO BE, and do a gap analysis. Looking at where you are in the beginning and where you want to be will shed light on a lot of bad habits and dirty laundry. I’ve seen a lot off issues be resolved during a transformation that weren’t agile related, they were things that needed to be fixed regardless of methodology. If find that the root of most problems is mistrust, poor communication and translation, and a lack of respect for the others on the team.

Any suggestions on how to manage leadership transformation “speed” expectations beyond the transformation scrum team if we cannot get that level of commitment? I have heard the statement: “A three-year transformation? Not acceptable!”

Visually show them what it takes and include the things that can derail it. I use an agile approach to say, “Let’s create a backlog of all the stuff we need to do, identify the value and prioritize. Let’s find an agile transformation MVP. Then with that, let’s identify what we agree we have to do within their expected time frame to achieve our transformation KPIs.” I can almost guarantee you, the time they are allotting isn’t enough.

I’d also have a conversation about what our blockers are. I will tell you, the number one block is that in their time frame, they likely have other competing initiatives. The inability to keep on schedule is typically caused by trying to change too many things at the same time and not assessing the impact.

As a Scrum Master, what can you do about technical leadership that will not modify their behavior to change from a “firefighter” and “getting-lost-in-the-weeds” mentality to an “employee growth and enterprise vision” role?

One thing that can sometimes get management to evaluate their thinking is to introduce the idea of a maturity model to show them that you are stuck on Level 1 or even Level 0 of the agile maturity scale. In order to mature, we need to look at what it takes to create a more mature agile environment. Let us know if we can help you with that!

How do we convince business owners to accept a true MVP with features as subsequent iterations when they are used to getting everything at once?

Show them the numbers. We have to get business owners, product owners, and product managers to become stewards of the company’s money and answer the question, “What is the ROI?”. Why would a responsible BO/PO want to spend $500,000 on a $25,000 ROI? What we have to show them is that every story point costs money, and they have to ask, “Is this story or requirement worth what I’m willing to spend on it?”.

Have you found that an Agile governance structure is helpful to coach and guide people through an Agile transformation? If so, what structures have you found successful?

This is a whole topic in itself and I have this in my queue for my next workshop. You will notice in several responses that I mention maturity models (which I heavily advocate). There are some governance models which I’ve used, but I caution people not to be too heavy-handed with them. More to come on this…

Why would we stop recognition of individual achievement? We need to be sure that we are reviewing and rewarding both team work and individual work. For example: maybe an individual isn’t contributing to the team. That needs to be looked at from both the individual and the team levels.

I often set up ways for the team to recognize individuals – especially individuals who have helped make the team perform better. When management recognizes individuals, it can promote an environment in which people to act badly toward their team or group members as long as they are pleasing management. This goes against the agile culture and mindset that we want to encourage.

What is the Lego thing again?

LEGO® Serious Play® is a workshop that uses LEGOs to help facilitate leadership and team members getting on the same page and building a common understanding of what the future state will be. Check the course outline for more details!

What do you think are Agile’s selling points –without overselling it by saying that it is faster and cheaper?

This is actually a question that I asked the attendees. I enjoyed hearing what they had to say and wanted to share.

• Faster feedback
• More collaboration among team members
• Less likely to do the wrong things
• Better transparency to progress
• Saves money
• 21st century thinking
• Delivers value sooner to the business
• Frequent checkpoints ensure real business needs are being met
• The team will deliver real value earlier and with more quality than with waterfall
• Helps us discover issues earlier
• Faster value delivered
• Better innovation
• Right value. Right time.
• Better morale – teams are more engaged
• Iteration gets the product to the customer for review more quickly
• Can capture missed requirements faster; ability to adapt to ‘I don’t know what I don’t know’
• Empowerment to make the right decisions at the right time
• We seem to want the fruits of Agile without sowing the seeds for it first
• Deliver small value sooner

I hope these answers provide some guidance on how to sell leadership on the realities of an agile environment and how their buy-in and support is required to make it work! If not, and you need more help, please let us know. I also recommend taking a look at our Management 3.0 course. It is a unique, workshop-style class was developed specifically for agile management.

– Jacqueline

Do you have a question about agile leadership?

Let us know and we’ll get you an answer!

Submit Question