Imagine being tasked with learning to play jazz. Working the scales. Memorizing songs. Over time you would develop a level of talent regardless of passion. You would probably even get good enough for gigs with a local bar. This would probably be good enough to fulfill the task of learning jazz. It wouldn’t get you to the level of Louis Armstrong though.
Stuart Miles – www.freedigitalphotos.net
Attempting to move your team to Agile is the same. Put the proper processes in place. Follow the rules. Over time a new pattern of work develops, one that is more Agile-like than the previous one. This new paradigm plateaus. It’s probably different enough than what was done before that everyone looks and says “yep, we’re Agile now.”
Over time the management that wanted the team to go Agile is going to get frustrated though. This new paradigm, it’s not what she wanted. She was promised continuous improvement. She thought the team would become high-performing. She was expecting to have a product to market more quickly, and more relevant to that market when it arrived. Something went wrong.
This is not a process problem. In fact, evaluating the teams process against the rules of Scrum, Kanban, SAFe, or whatever agile process was chosen is likely to result in their process passing with flying colors. The problem is that Agile is more than just a process.
I’ve recently finished a period of time as an IT Project Manager. At its heart this was a classic PM role. Capitol projects, such as updating a corporate PBX System, were at the heart of the job responsibilities. Those who know me well or followed this blog in the past might be surprised at this. I know when I speak to recruiters here in the Denver area they always are. That aside my big question as I started that position was what can I, as an Agile Practitioner, bring to this classic project management role?
Image courtesy of stockimages @ freedigitalphotos.net
At the start I made a tweet about bringing Agile to the company. Of course this is not something that one can just do, like bringing a stand-up desk. (Which I did near the end of my time.) Agile, especially as related to project management, is a way of working, a style, an approach.
After a week or two of settling in and finding my place on the team my goal was to excel in the job being asked of me. My efforts shifted to how I could do that. I was part of a team that ran very lean. We were under the direction of an extremely intelligent woman. All the projects I was involved in were already underway at some level. I was getting a good idea of what they required and where they were struggling, if they were. Thing is, what they required for the most part wasn’t anything I could easily pull from my Agile and Scrum background. Continue reading
The first listed principle at agilemanifesto.org lists customer satisfaction via delivery of valuable software as the highest priority.
Stoonn – freedigitalphotos.net
Some people interpret this to mean the more software that gets delivered the better. They even point to short iterations which include deliverable’s as a manifestation of that. More rapid delivery can even be a selling point to launch an Agile transition. Thing is, the goal isn’t more software, it’s valuable software. Continue reading
Despite their differing priorities a Product Owner (PO) and Scrum Master (SM) must be on the same team. More specifically, in a successful scrum team the PO must be a partner to the SM. Their adversity comes from the roles they play. The sentiment applies equally well to Agile Project Managers and Agile Coaches. That said, framing it in the context of Scrum makes the narrative easier.
meepoohfoto – FreeDigitalPhotos.net
The PO is beholden to the customer or end-user as well as the business. Their main function is to maximize value delivery. The SM is beholden to the team. Their main function is ensuring and enacting scrum through servant-leadership of the team. With no SM a PO might very well burn a team out by requiring too much of them. Without a PM a SM might hinder value delivery by shielding the team from more than they should or allowing more experimentation than the business can support. Hence a partnership must form between the PO and SM for a successful team to emerge. The adversity arises due to the difference in priorities between these two roles. Continue reading
While continuing to prep for my families move to Colorado next month I have decided to revisit a post or two from before. I may take a week off from writing as well.
atibodyphoto – freedigitalphotos.net
This post found widespread reading when it was first published in November of 2013. I’m adding it here as it was early in this blogs life and many people may have missed it back then. If you have seen it before all is not lost. I have gone through it and done some editing to make sure it’s still relevant.
When looking for information on Agile, software development is the most common industry represented. Within those results more often than not Scrum is used as the implementation. Many articles that try to talk about Agile in a generic sense use terminology from Scrum. A common side effect of this is that many people associate Agile and Scrum on a 1 to 1 level. This is a problem.
When a team builds a house the project has a very defined end. Once built the original team no longer deals with the house instead handing maintenance and support over to the user. Software development is not like that. Once the initial release is done the original team generally does deal with maintenance and support. When the last release is done they generally still deal with maintenance and support.
khunaspix – freedigitalphotos.net
This can be tough for some people tasked with managing agile software projects to reconcile. Projects are supposed to be temporary and have a defined end. Once a project is done it’s time to move on to the next one.
A good way to get around this mindset is to change the delivery. Don’t think about the software as a product to develop and deliver. Think about the software as a value delivery system. Your team is not creating this single product which will then be passed off and forgotten. Your team is creating value for the user. As long as there is more value in enhancing or fixing the software then there is in doing something else for that user then your team should focus on the software. That brings us to how we deliver more value on a product that is out the door. My answer, admittedly biased, is with an Agile mindset. Continue reading
I like to point out that Agile is going to look different from one company to another. In fact, it often looks different from one team to another. To get the most from an Agile transformation there needs to be freedom for the teams to adapt. This isn’t the whole story though.
Stuart Miles – FreeDigitalPhotos.net
Just as humans must walk before they run teams must start along an Agile path before they can create their own trail. It’s a truth that has been known for ages among many specialties over time. The most common reference is to Shuhari. The basic premise is that you start by imitating what someone else does. You then progress to modifying it to better suit your situation. You end the end up as a master that can create new ways of doing on your own. This same logic applies to attempting an Agile transition in a company. Whether the pilot program or the last team on board the truth is the same. Continue reading
There is a lot of work being done on scaling Agile. This makes sense. There are few people anymore that will argue against Agile methods on a small-scale. The problem is that many organizations are not small. Plugging these small-scale changes into the greater organization can be difficult and often has mixed results.
stockimages – freedigitalphotos.net
Any organization looking to scale needs to know why they want to scale. They need a plan to scale. They need a way to evaluate whether their transition is working.
A good way to think of what’s happening is by imagining a city skyline. Spreading Agile to all teams is equivalent to building more skyscrapers across the horizontal landscape. Scaling Agile in the organization is more like extending the existing skyscrapers higher in the vertical plane. The analogy isn’t perfect of course. Scaling will require more horizontal involvement and spreading will require a degree of vertical integration. The important part is the focus and most movement is in a different direction scaling than it is for spreading.
We’ve all been there. Here in the Northern US it happens like this. It’s the dead of winter. The days have been getting shorter and darker. The weather has been increasingly trapping us inside while simultaneously making our daily commute longer than ever. January first approaches and we make some resolutions, providing focus and hope. We work hard towards these new goals. We see some positive change. Progress is made and it makes us feel good. Then something happens.
anankkml – FreeDigitalPhotos.net
Sometime in late February or early March is when we tend to first notice it. We’ve lost momentum. Progress has stalled, and we aren’t really sure when it happened. We might have lost the initial progress. In some cases things have slid even further back then when they started. Most of the time by May it’s as if nothing ever happened.
Many Agile transformations are the same way. They start strong. Everyone has really good intentions. A couple of process changes are made. Some benefit is seen. Some resistance is met with facets of change that are uncomfortable. Concessions get made. The result is little change, minimal benefit, and stalled change initiatives. Continue reading
This is hard for me to say. I like to solve problems. Most people reading this also like to solve problems. It’s in our blood to fix what’s broken, improve what’s inefficient. It can also be a mistake.
meepoohfoto – FreeDigitalPhotos.net
I’ve talked about this before. At the start of the Back to the Basics series I posted about Tensions to Manage. I’ve thought about this topic more lately as I’ve read about the shift in attitudes towards estimation. The desire of strategic decision makers for estimates is a tension at odds with the desire for the Agile Team to concentrate on the now. The solution doesn’t lie in eliminating all estimates. Likewise the solution doesn’t lie in forcing the team to do detailed estimates for everything. The solution is to manage the tension, not give a final answer.
These situations are common in an Agile transition, especially in the early days. To maintain our sanity as coaches we need to realize that not all problems need to be solved immediately. Continue reading