Constantly Improving Business Processes.

Category Archives: Implimentation

Often organizations will start an Agile journey by sending their project managers and/or development leads to Scrum Training. Upon their return they are expected to implement Scrum with their new training and knowledge. Sometimes this is driven by one of the groups sent to the training, but often it is an edict sent down from upper management. In either case this is setting the organization up for a rough transition to Agile.

Naypong – FreeDigitalPhotos.net

In general smooth agile transitions require more than an internal employee bringing info in from a two-day course. Support is needed from every level of the organization to make things work. Involvement is needed from everyone who will be working on the project teams. Different roles need different training to succeed with their new process.

Sending someone to training is a good start to the transition. A better start would be to send an entire team. This shouldn’t be a team of project managers, but the pilot team making the initial switch to the agile method of choice. This prepares the pilot team for success.

When the team returns they should meet with their management support. Two important things happen here. On one side management can communicate the hopes they had in starting this process. The other side is that the team can communicate what they expect to see happen in the first six months. This doesn’t have to be a confrontational time. Management saw some possible value in this to begin with or they wouldn’t have sent the team off. Bringing in an outside consultant can help keep everyone on track. The team is new to the whole thing, but should know enough from training to set some initial expectations for management. Chances are the team will not be able to transform as radically as management initially thought. On the flip side they should be able to promise greater transparency into what is happening during the transition than management expected.

With an entire team trained and proper expectations set between the team and management the actual transition can start. In a perfect world the team is working on a project that requires nothing from other teams which may impact the new processes they are putting in place. In reality they will likely be interfacing with teams that are not agile and not working to get there. This is where the team all being trained in agile values and principles can be more valuable than the specific method training they have received. Most of the current popular agile methodologies do not deal much with interfacing outside of the team. They tend to assume the team itself will be doing everything from start to finish with no reliance on the outside.

Even with these pieces in place it’s not guaranteed that the transition will be smooth. In fact, real-world evidence is showing that the transitions are almost always rough. By getting everyone trained, on-board, and supported that roughness can be smoothed out. Bringing in outside help is another way to help smooth out the rough spots that are tough to see from within.

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 →

I spend a decent amount of time pointing out that every Agile Journey will look at least a little different. I appreciate frameworks such as Scrum. Having a defined process to follow generally makes the initial start of a transition much easier.

In the last post I pointed out that change has to start somewhere. In fact, I would state there is no Agile Journey without change. Being Agile is deeply rooted in responding to change. It’s one of the main values from the value pairs. An Agile journey with no change is as useful as a cancelled cruise is fun. Continue reading →

We all played at it when we were younger. “If you were stuck on a deserted island and could only bring one person/item/food what would it be? As we prepare to enter the new year I thought I would ask a similar question. If you has to start down the path of Agility with only one process what would it be? This isn’t about what one value pair or principle you would follow. As an Agilist I hope that your preferred process does line up with one, but that’s not the point. All change has to start with something. If you were only allowed to do one change at the outset, what would that change be?

Maybe you would start with iterations in hopes of rapidly delivering value to your customer. Perhaps your first order of business would be to change your teams so that developers, testers, and business representatives are working together on product teams instead of separately on functional teams. It may be time for you to bring your product team and your customer together for some direct interaction.

Whatever the single step you could take is you should move forward with it. Every team and situation is different, and as such there are multiple right answers for what one thing you should start with. As a coach or agile change agent you may have a favorite that you lean towards starting with. I’ll be back after the new year to talk about my preferred starting point and why. In the meantime, feel free to share your preferred starting point and why.

Agile transformations affect the entire organization. Successful transformations require participation from everyone in the organization. The teams have to be willing to try new ways of working. Management needs to be willing to try new ways of determining success. Executives need to be willing to try new ways of measuring value. It can even be more specific with Human Resources needing to find new ways to structure compensation and legal finding new ways to structure contracts.

Failed and struggling Agile implementations often leave someone out. Sometimes it is a bottom up process struggling with blockers or legacy process. Other times it may be a top down initiative fighting teams that are against changing their process. The problems can even be external where a client will not, or cannot, accept a new contract structure to support Agile. In any case the more people on board, the greater the probability of success. Continue reading →

It has been a little over a year since I launched this blog, and approximately 6 months since my last blog retrospective. I have been reflecting in the interim, but have not taken any time to specifically reflect and adjust.

In the last six months I have kicked off a new style of post called Red Flags. I also have made an effort to have some type of image, preferably relevant, for every post. I also have finished out the initial Back to the Basics post series talking about the value pairs from the Agile Manifesto. Continue reading →

One idea that confuses people when moving to Agile is the concept of the cross-functional team. The idea is that the team has all the skills necessary to move every item from pending to done by the end of the iteration. The wording is that the team is “self-directing and cross-functional.” Many people read that and start to worry about having a team of generalists that can accomplish any given task at any moment.

This can lead to very unsatisfied team members. Imagine this same situation in a restaurant. The head chef would possibly bring guests from the front door to a table while the bartender may have to make side dishes. Not only would this result in sub-par products, the people in question would likely look for new jobs.

I have good news. People do not need to seek new jobs because this is not the intent of cross-functional Teams. Continue reading →

The Product Owner. Part of the team; apart from the team. The final answer to the question “what?” The primary respondent to the question “why?” She knows what the users want. He understands what the users need.

The Product Owner (PO) has a great amount of power. (And responsibility – “With great power comes great responsibility.” – Stan Lee via Uncle Ben) The PO ensures the Development Team produces value. In scrum the PO is the keeper of the Product Backlog. The PO is one person. The PO is the final authority for the product. The PO role is not to be taken lightly. It must be given to the proper person. Who that right person is depends on a lot of factors. Continue reading →

Most Agile Journeys begin with Scrum. As I was reading through a blog post over at agileheads it occurred to me that what to do with the Project Manager is perhaps the biggest mystery in Scrum.

Think of it. A classic project team goes to Scrum training together. The Project Manager, the developers, the testers, the analysts. Perhaps there’s even a customer representative that goes, or someone from sales. Out from the training should emerge a Scrum Team, (Product Owner, Scrum Master, Developers) and Stakeholders. In this case “Developers” are not equal to “developers” – but we’ll look at that another day. There is no PM in that list. No “boss”. So what happened? Does the PM stay in the training room forever? Did they sneak out the back – no longer part of the team? Continue reading →

Six months is a long time to wait for a retrospective. It is possibly the most important part of any Agile process or methodology. It’s right in the Manifesto: Responding to Change. In fact, the 12 Principles stop just short of calling it a retrospective, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” To be fair, this retrospective is different. This one is not for the company where I work, it is for this blog. Continue reading →