I have a new article up on agileconnection.com called The Case for #NoEstimates.
The idea is to produce value instead of spending time estimating. We have a vigorous “debate” going on in the comments. I have client work today, so I will be slow to answer comments. I will answer as soon as I have time to compose thoughtful replies!
This column is the follow-on to How Do Your Estimates Provide Value?
If you would like to learn to estimate better or recover from “incorrect” estimates (an oxymoron if I ever heard one), see Predicting the Unpredictable. (All estimates are guesses. If they are ever correct, it’s because we got lucky.)
Since the dawn of time, inquiring minds have wanted to know… “What really happens in the Women’s Restroom?! Why do they go in twos? Are they crying? Gossiping? Pillow fighting? WTF?!
Answers have remained a mystery… until now. Turns out, this seemingly innocuous space has one very big secret! Axosoft has used their agile powers to infiltrate the system and break the bathroom code once and for all! The most shocking part… It was right in front of our faces this whole time! That’s right, the passive woman plastered on the outside of bathrooms around the world, the one wearing a triangle dress, has been holding in something bigger than pee pee (and we’re not talking #2)! The secret she holds every single day will be revealed at the Girls in Tech Catalyst Conference and all we can say is… It was never a dress!
What is the goal?
I seem to lead with that question a lot these days. Is the goal to practice Scrum? Is the goal to apply SAFe? Is the goal to use some other Agile delivery framework? Is the goal to uphold the values and principles of the Agile Manifesto?
They are all means to an end. Your goal depends on your organization. Fundamentally, every for-profit organization I’ve come in contact with has pretty much the same primary goal. Make money!
Before committing budget for that next project, let’s first ask ourselves if we know our core business drivers.Common Business Drivers
- Higher Quality
- Shorter time to market
- Lower Costs
But let’s look at this again. What is the primary goal? Make money!How do we achieve the goal?
- Through predictability, we get better at forecasting sales and delivery (lead times)
- Through higher quality, we lower costs of rework and increase customer satisfaction
- With shorter time to market, we can get an earlier ROI and increase cash flow
- With lower costs, we free up capital for other areas of our organization
- What is your primary organizational goal?
- What are your core business drivers, relative to your primary organizational goal?
- If you don’t know the goal, how do you know where to spend your time or money?
- How do you know where to start?
I've been giving some careful thought to why it became necessary to create the concept of Enterprise Services Planning.
At the most fundamental level, ESP was necessary to provide a container for the collection of things we were teaching that were beyond kanban systems and beyond the scope of the Kanban Method. These were the things that enabled the optimal and effective use of kanban systems - topics such as: probabilistic forecasting and statistical analysis; qualitative risk assessment; real option theory; connecting strategy to operational mechanisms such as Kanban capacity allocation; and so forth. ESP represents a system of management for an entire professional services business. It isn't just an IT thing and it certainly isn't just for operational management of a single service delivery workflow. So we needed a name that encompassed concepts that were a lot bigger than Kanban.
Recently, I've taken a new approach to teaching The Kanban Method. The new Lean Kanban "Practicing the Kanban Method" class is built around the 7 Kanban Cadences - the cyclical meetings that drive evolutionary change and "fit for purpose" service delivery. Two of these meetings are relatively new additions to the method: Risk Review added in 2014 as a response to Klaus Leopold formalizing Blocker Clustering in 2013; and Strategy Review as an emergent response to the concept of "fit for purpose" and the need to sense the external environment, in order to be able to respond appropriately. The other 5 were existing elements of the method, though the first edition of my Kanban book ommitted Service Delivery Review. In truth our training has not until now emphasized these meetings and particularly replenishment/commitment and delivery planning have not been explicitly taught. Little wonder then that these very basic functions of Kanban have not been well implemented in the field.
The year? 2015. The setting? An Agile transformation near you. The problem? You’ve hit a wall. Despite all your best intentions, you’re still not getting those promised benefits of Agile: speed, quality, value, sustainable growth across your organization. And your problems don’t stop there. You aren’t responding to market threats; you can’t even see market threats; you’re unable to retain great employees; you’re not an industry showcase. In the end, your Agile transformation has brought cynicism and distrust.
You may have heard me talk about “12 Agile Adoption Failure Modes” that concentrated on agile failure in the context of IT teams. Given the expanded adoption of Agile practices in organizations beyond the IT group, the threat of failure is now farther-reaching, with bigger impact.
Now it’s imperative that we look not just at Agile adoption, but at Agile transformation — where organizations move beyond Agile principles within their IT groups to business agility. To accomplish this, we transform from just doing Agile to being Agile.
Over the next few weeks I’ll share with you the top 12 failure modes of an Agile transformation that I’m witnessing in my work with organizations around the globe. Following are the first three.1. Lack of Executive Sponsorship
This failure mode evidences itself in several different ways and ultimately, it warrants its spot as the number one failure mode and drives all the other failure modes. Also known as “buzzword buy-in,” a lack of executive sponsorship can come at you from two directions
Imagine a small group of techies eager to adopt Agile in their team. With no executive sponsorship, they perform in a stealth environment — sort of a “skunkworks” adoption — under the radar of the existing organizational structure. Why? Because they’re hiding from the hierarchy of management (see the second failure mode, below) which could shut down their effort, and evading the current gate-driven approach to product delivery. While the project may gain some momentum, deliver value faster, and stir the souls of those involved, its sustainability is improbable. Lack of executive sponsorship will limit visibility into the team’s success and provide insufficient support for adoption across subsequent teams. Agile adopted this way will likely die.
In our second scenario, an executive decrees a switch to Agile delivery across the entire IT organization, but there’s no real follow-through: it’s simply a “checkbook commitment.” The executive demands immediate results, yet doesn’t change the metrics by which success is measured. Unengaged, the executive proclamation for an Agile adoption will never move to a true business transformation. At best, without the executive’s continued engagement, the organization will only have pockets of Agile success, typically limited to the team level. The organization will probably grow to blame Agile (and each other) for decreased quality and productivity. And the executive’s resignation letter will conveniently not include the word “Agile” in its summary of successes.
How do we prevent this failure? Leaders must accept that a successful transformation is a journey. Along this journey, leaders seek guidance for a transformation with a broad, sustainable impact. As part of the transformation they make a personal commitment to their teams, and in turn they recognize the personal commitment they are asking of their employees. Executives commit to measuring success differently from before, because the work is different from before. Success now favors value delivery, and time for learning is built into the transformation. Ultimately, success is celebrated across the organization and setbacks are seen not as failures or cause for blame, but as opportunities for learning and growth.2. Failure to Transform Leader Behaviors
Isn’t it great to have managers who just get things done? They know the right actions to achieve success; they direct their teams to perform these actions; and they have the power to control all aspects of the work and do whatever it takes to get it done.
Let’s pull this apart a little. When a manager tells the team what to do, there’s a false sense of success via control. When a manager powers through difficult circumstances regardless of the impact on the team, they leave the wisdom and the morale of the team behind.
Such a management style is a classic Agile transformation failure mode. All the team-level Agile practices in the world mean nothing if the manager doesn’t embrace a behavior that is more in service to the team than control of the team. Robert Greenleaf’s work identifies the characteristics of what he calls a “servant leader”: one who serves by leading, and leads by serving. An Agile transformation success story hinges on the ability of the leaders in the organization to take on these characteristics:
Systematic neglect: knows the limits of how much focus can be allocated to issues; learns what to focus on and what to let go of in order to support the team and achieve goals effectively
Acceptance: knows when to let go and trust the instincts of the team; accepts the wisdom of the team and is prepared to support it
Listening: facilitates useful and necessary communication, pays attention to what remains unspoken, and is motivated to actively hear what others are saying
Language: speaks effectively and non-destructively; clearly and consistently articulates the vision and goals for the team
Values: is responsible for building a personal sense of values that are clearly exhibited through consistent actions; supports team behaviors that build their sense of values
Tolerance of imperfection: modulates his or her own sense of perfection and offers to each team member an understanding of their strengths and challenges; cares more about “How can I help the team grow?”
Goal setting: owns the vision; doesn’t advocate for a personal belief in what is right but rather maintains the goal for a higher purpose, inviting others to align with the vision for the overall good
Personal growth: recognizes the value of continually finding diverse disciplines that invite new ways of acting in service to the team, and models this growth behavior to inspire others
Withdrawal: knows when to step back and allow the team to figure out its course, versus inflicting a personal sense of what is right for the team; carefully decides what to bring forward and when
What is your current organizational structure? How many layers of management exist around each Agile team? How is governance perceived, and who is ready to break down walls to make sure that value flows through your organization?
Failed Agile transformations suffer from an inability to change the existing organizational structure. What do I mean by this? Typical organizations have been set up for sub-optimization: that is, they measure success by departmental performance, versus overall value delivery. Here’s what that looks like: In the book This Is Lean, authors Niklas Modig and Par Ahlstrom depict a soccer field scattered with teams, each one in its own tent. Success is defined as any one team getting the ball out of its tent. But is that really success overall? In this scenario, as in our traditional organizations, we create accidental adversaries. We limit visibility of the organization’s overall effectiveness, and focus on our team’s success at the expense of success for the organization.
True Agile transformations push the boundaries of these existing organizational hierarchies. In the soccer field metaphor, we remove the tents. Now everyone can see where the ball is, where everyone else is, where the goal is positioned, what the referee is indicating, what the coach is saying, and what the scoreboard says. In your effective Agile transformation, you know what the true value is, you know who needs to be involved in order for the value to be delivered, and everyone associated with the value delivery has visibility into the current state of the value stream, including its blocks. They see the goal as successful delivery of value to the customer, and they coordinate as a whole to deliver that value.
Here’s another symptom that your organizational infrastructure is crippling your Agile transformation: Does your organization cling to a notion of efficiency based on resource usage — believing that loading people to 100% capacity is the best way to get work done, and then measuring people annually by how well they deliver in this fully-loaded mode?
To incent greater collaboration and communication, you need to revisit how you appraise work. Instead of annually, by individual, 100% utilized, with MBOs set 12 months earlier, you should invite frequent feedback; focus more on team effectiveness; and bias performance appraisal toward efficiency of value flow versus efficiency of workers.
If you’re not feeling the discomfort change brings, you aren’t truly transforming. If your transformation isn’t requiring you to invest in the technology and culture to support a new mode of visibility and collaboration, you aren’t truly transforming. If you’re adopting some Agile practices at the project level without looking at the bigger picture, your Agile transformation is poised for failure. And Agile, not the failure to transform the organization, will get the blame.
Stay tuned to the blog for Jean’s next three Agile transformation failure modes.
You may have just returned from an internal meeting where you were given some new orders to “go agile” with your team or group.
You may be responsible for leading an agency (or a professional services team) within your organization to “go agile.”
Your team is responsible to #deliver “using agile” or “using scrum” (This last posting may also help — “Holy CRAP I have to do THIS???”)
Now. The pressure is on for you to do this TODAY.
Your boss — or some other stakeholder — is demanding results. Lucky you!
Do you feel a bit out of control or caught between a rock and a hard place?Are you STUCK?
Here’s the secret:
You CAN enable the team to run in an agile manner using Scrum (or something like it).
It’s pretty easy actually. In real life, “easy” is anything BUT that (you know there is no Silver Bullet).
Let me help you. Let’s talk.
Here are TEN FREE STEPS to start on your own:STEP ZERO:
I have this sinking feeling you may want to do this with all your teams and clients across the organization. You want to jump in and scale this agile stuff in a big way and just GO FOR IT.
This is not time for you to panic. This is not the time for you to make a career-limiting-move.
Here is what you can do.STEP ONE:
Identify your most important (valuable?) client today.
Think about the pareto principle (80/20 rule).
You DO have those very valuable 20% of customers who DO provide you with 80% of your success.
Focus on them and use Scrum to #deliver with them.
Actually. Start with just ONE client (or customer).
Yes. This means you will have to say NO to a lot of people.
Remember that 80% of your current clients are keeping you up at night on wasteful non-value-added crap. You may piss them off by saying NO; however, they are probably already pissed off at you and the cost of switching is either too high or they do not really feel enough pain and love blaming someone anyway.
They are not your problem. If you are bleeding now, this is not the time to keep doing whatever it was that you were doing in the past.STEP TWO:
Have a real face-to-face conversation with your customer (or client) about playing the role of “Product Owner” for the ONE Scrum Team.
This is a HUGE commitment. Amazing things happen when you ask. I’ve seen it done and have helped others do this. What seems unreasonable today really can happen when you Focus and #deliver together.STEP THREE:
Dedicate a team of 5-9 people that can #deliver with your Product Owner on this Scrum Team.
Identify someone to play to role of the ScrumMaster; this person should have real world experience and failures someone else has paid them to make!
Watch the magic happen.STEP FOUR:
Create an initial Product Backlog together as a Scrum Team. This should be based on the highest value project with a clear vision of the WHY effectively communicated by the Product Owner.
Don’t worry about estimating at this point. Read up on the topic of #noEstimates and learn to Focus and #deliver together… as a real team.STEP FIVE:
The Product Owner can prioritize the Product Backlog items however they feel is necessary. Use Story Boarding or other ways to tease out the REAL value to your end users. Oh… and do this quickly (think hours or two days MAX because there is no such thing as a “Sprint Zero”).STEP SIX:
The Scrum Team can then plan their first Sprint using the Scrum Master as the facilitator. The Development Team can figure out what to commit to (or forecast) for this Sprint (or Iteration).
Here’s the thing… they will be wrong. It’s OK. Focus and #deliver SOMETHING. The weather forecast is rarely right in the real world… but we learn to adjust real life to the real weather conditions as we learn more together.STEP SEVEN:
Have a daily stand-up meeting each day for a short iteration (how about one week to get started!?!?!).
Allow for the team to coordinate on the Sprint Goal and meeting the Definition of Done for the Sprint.STEP EIGHT:
Do the work. Daily. This is where the miracles can happen and will evolve over time as your dedicated team becomes high performing [did I mention this will take time]?STEP NINE:
At the end of the Sprint, host a Sprint Review. Demo your Potentially Shippable Software — or Product Increment — together as a Scrum Team. Have your Product Owner stand up and proudly show what the team was able to actually #deliver.
Gather feedback from your key stakeholders, project sponsors, and perhaps even you real world customers (or end users!).
Focus. #deliverSTEP TEN:
Gather your team for a Sprint Retrospective.
Learn together about what can improved in the next Sprint.STEP ELEVEN:
Need help?LET’S TALK
WARNING The proverbial shit will probably hit the fan. Bad things WILL happen. This is totally normal.
As time takes time, the team DOES #deliver something.
Remember: Delivering the wrong thing TODAY is better than delivering the wrong thing months — or years — from now.
This is all good.
I can help.
Last month, Forrester released a wave of portfolio management industry reports. In the Portfolio Management for Tech Management wave, Rally was named among the ten most significant portfolio management software providers, and was the only Agile vendor featured in the report. The inclusion of a pure Agile vendor reflects the growing importance of executing portfolio plans faster to hit critical market windows.
In midsize to large organizations, delivering business value faster requires scaling Agile practices to coordinate a large number of teams to deliver on an entire portfolio scope. But a good strategy is irrelevant if you can’t deliver on it in the timeframe required to stay competitive. As companies realize this, faster portfolio execution becomes an imperative.
At the same time, many of these companies still have traditional financial controls that impede their ability to respond to market changes: project funding that locks in requirements for long periods of time and mandates that developers leave their environments to fill out timesheets — a process that often results in inaccurate cost reporting.
Changing those financial practices takes time — and you can’t afford to wait. If you work in one of those organizations, you can still scale your Agile practices to deliver faster by integrating the Rally platform with PPM vendors.
Planview — one of the leading PPM vendors — has been honing its integration with the Rally platform for several years to create a realtime connection between traditional portfolio planning and Agile portfolio execution. The latest Rally-Planview integration provides added granularity into the visibility of Agile projects from PPM dashboards. When adopting Agile, the more visibility you can give to business leaders, the faster they can adapt their plans to respond to changes.
I have an article up on agileconnection.com. It’s called How Do Your Estimates Provide Value?
I’ve said before that We Need Planning; Do We Need Estimation? Sometimes we need estimates. Sometimes we don’t. That’s why I wrote Predicting the Unpredictable: Pragmatic Approaches for Estimating Cost or Schedule.
I’m not judging your estimates. I want you to consider how you use estimates.
BTW, if you have an article you would like to write for agileconnection.com, email it to me. I would love to provide you a place for your agile writing.
The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.
I’ve been in some debates recently about whether the ScrumMaster should be full time. Many of the debates have been frustrating because they devolved into whether a team was better off with a full-time ScrumMaster or not.
I’ll be very clear on the issue: Of course, absolutely, positively, no doubt about it a team is better off with a full-time ScrumMaster.
But, a team is also better off with a full-time, 100 percent dedicated barista. Yes, that’s right: Your team would be more productive, quality would be higher, and you’d have more satisfied customers, if you had a full-time barista on your team.
What would a full-time barista do? Most of the time, the barista would probably just sit there waiting for someone to need coffee. But whenever someone was thirsty or under-caffeinated, the barista could spring into action.
The barista could probably track metrics to predict what time of day team members were most likely to want drinks, and have their drinks prepared for them in advance.
Is all this economically justified? I doubt it. But I am 100 percent sure a team would be more productive if they didn’t have to pour their own coffee. Is a team more productive when it has a fulltime ScrumMaster? Absolutely. Is it always economically justified? No.
What I found baffling while debating this issue was that teams who could not justify a full-time ScrumMaster were not really being left a viable Scrum option. Those taking the “100 percent or nothing” approach were saying that if you don’t have a dedicated ScrumMaster, don’t do Scrum. That’s wrong.
A dedicated ScrumMaster is great, but it is not economically justifiable in all cases. When it’s not, that should not rule out the use of Scrum.
And a note: I am not saying that one of the duties of the ScrumMaster is to fetch coffee for the team. It’s just an exaggeration of a role that would make any team more productive.
Finding your next most important thing is critical and requires clarity. As teams begin thinking about how to address their meetings, the topic of a previous post, its critical that they first identify where the team needs to focus its energy over the next 1-3 months, or the “next most important thing” the team needs to do in order to succeed.
So, how would a team go about identifying their “next most important thing”… It’s a fairly straightforward process.
For the sake of a tangible example, I’d like to use a set of three types of teams that I work with on a regular basis, teams that operate within a three tier enterprise product development structure. These teams and their purpose would be defined as follows:
- Product development team: Produce the next most important working increment of product within a couple of weeks.
- Program team: Establish and provide clarity for and to product development teams about the next most important increments of product that are needed within the next few months.
- Enterprise portfolio team: Establish and provide clarity for and to program teams about their next most important thing for the portfolio to succeed. This usually requires creating or maintaining a multi-quarter capacity-aligned roadmap for the products and services that are owned by the portfolio.
With these perspectives in mind here is the process that I would recommend for identifying the next most important thing within each team:
- Review the team’s primary purpose,
- Ask each team member to write down the one thing within its control that is keeping the team from fulfilling its primary purpose,
- Review the team’s suggestions and filter the list down to the one thing that the team agrees is the most important goal for the next period.
It’s important to recall that the next most important thing for a portfolio team may look very different from the next most important thing for a product development team.
So, how would a portfolio team member identify the portfolio’s next most important thing? I’d recommend that they answer this question:
What is keeping our portfolio from delivering the next most important increments of product into the markets within the next 3-9 months?
Likewise for a program team member I would recommend the following question:
What is keeping our program from providing clarity to the product development teams about the next most important increment of product?
And finally for a product development team I would recommend the following question be answered:
What is keeping our team from delivering a working increment of product within a couple of weeks?
In each of these cases, the next most important thing would be directly tied back to the primary purpose for the team and would be expected to be resolved within a short period. Once we know what the next most important thing for the team is, we can start to identify which types of meetings we will need and how frequently we will need them to ensure that we are accomplishing our next most important thing.
What do you think, are there other examples that you would like to hear more about or perhaps where you have seen this fail?
And as always, thanks for reading and sharing your feedback!
Here at Axosoft, we love our tech community, and we recognize the significant yet still underrepresented achievements and initiatives of women in the technology industry in AZ and abroad. As a tech company with a female CEO, we are not only active in supporting the tech community and championing the women at its forefront – we are actively seeking to expand our female workforce by adding more female developers to our team.
What better way to find female developers than to help create them? Don’t worry, we don’t mean in a creepy futuristic cloning way. Axosoft has partnered with CodaKid, a Scottsdale-based kids computer programming and game design academy, to offer fun and free workshops and codeathons that teach girls how to code as early as age 6.
We are constantly trying to align ourselves with great partners like Girls in Tech and CodaKid who share our vision for growing STEM education and the tech industry. As prominent players in the Valley’s technology ecosystem for over a decade, we are honored to be the lead sponsor of the Girls in Tech Catalyst Conference!
The speakers at this event represent some of the very best technological innovators, thinkers, entrepreneurs, and leaders in the Valley. And, it just so happens they are women. These superheroes, alongside the attendees of the conference, showcase just how strong, energetic and productive a network of driven and influential women exists in Arizona. This conference shows off the amazing women doing things right now on our own turf, and in doing so represents similar innovations globally.
We are SUPER excited to partner with Girls in Tech in celebrating the vibrancy and diversity of this growing movement, sharing in their vision to empower women in the technology industry, spread knowledge and inspire more companies like ours to create the next big thing.
So, how are the people challenges of DevOps more important than the technical challenges?
Recently I was reading Puppet Labs’ State of DevOps Report. Similar to VersionOne’s 9th annual State of Agile™ survey, this report has an interesting set of conclusions about the current state of DevOps. One of the things that I’ve been considering for some time is the strange proximity of DevOps people to technical problems.
There are a lot of technical aspects to doing DevOps. One example is continuous integration. When releasing, everything needs to be integrated and checked, no matter how small. DevOps takes it one step further with continuous deployment since you need to set up acceptance tests and unit tests, and all tests have to be automated.
One of the aspects of DevOps that reading this survey reinforced for me is that the folks who do DevOps the most successfully focus on the people aspect as much as, or sometimes even more than, the technical aspect. This brings the Gerry Weinberg conundrum to mind. Gerry Weinberg, considered by some to be the grandfather of agile, said that there’s always a people problem. The technical focus of DevOps may lead you to think that there isn’t a people aspect to focus on. In reality, while the technical piece is a focus, the people problem is huge and even more important.
DevOps is about bringing the functions of operations and development together, which means you have to break some stereotypes. You have to think outside the box. Those on the DevOps team must have the will to think about each one of the development stories through the post-deployment lens. Do you have monitoring as part of what you’re doing? Do you have performance constantly tested? Do you have all aspects of your tests automated? If not, then you’re probably not going to be as successful with DevOps.
This sounds technical, but it’s actually more of a people problem. It’s employing DevOps engineers who remember to do that. It’s not asking the question of should you automate, but how will you automate this specific story? That’s huge and it’s vital. It needs to be addressed and it needs to be addressed successfully. If you don’t, then you’re not tall enough to ride the ride. It’s not worth your time and energy to claim to be DevOps if you can’t do those things. DevOps takes time, energy and nurturing. It takes the willingness for individuals to step up. And it takes the willingness for management to step back and give your people the opportunity.
There were a couple of other fascinating people issues that that survey brought to light. The number one key to success in an IT organization, according to this survey, was employee happiness. This is an aspect people need to listen to this and build on. Employee happiness is number one. It proves that even geeky programmers like me don’t derive our employee happiness only from the really cool tools we get to use and work on. It’s nice, but it’s not enough.
The other fascinating people issue was getting the whole team together to work on the issues, thus becoming a cross-functional team. Everybody is responsible for everything, and that makes a huge difference in the DevOps world, even more so than in the traditionally agile world. Teamwork is where you’re really going to see the difference between just checking things in all the time and continuous deployment.
DevOps lends itself to being viewed through a technical lens, but the people aspect is what differentiates you from success or failure. I hope I have inspired you to take a closer look at how you are balancing the people aspect of DevOps with the technical.
So, what are some other people aspects of DevOps that should be focused on?
Need assistance with a Continuous Delivery/DevOps Assessment? Click here for info.
VersionOne and State of Agile are registered trademarks of VersionOne Inc.