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.
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.
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.
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.
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.
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?
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.
I’ve recently read a little about Personal Kanban. The first exposure I had to the concept was a parent using Kanban as a weekly chore board at home. I’m pretty sure this one was the first. Since then I have discovered many more. There are also many similar methods that have been in use among home life bloggers for a long time. Today we’re taking a look at the Agile Journey from a different perspective. I’ve mentioned before that Agile is an approach or a state of mind more so then a prescribed set of practices. Because of this the Agilist will naturally approach life situations outside of work in an Agile way. The one that sticks out to me the most is the family road trip.
Like many modern American families we have relatives in multiple states. They are concentrated in Minnesota and Colorado. Neither family has the level of wealth that would make this a regular weekend flight. Truth is, even before the four of us all required tickets we didn’t fly it every time. The cost for driving hovers around the 2-3 airline ticket level depending on what stops are planned and what the meal setup is. Non-stop driving puts the trip around 14 hours. (Non-stop includes gas and bathroom breaks, possibly drive-through’s as well.) Driving non-stop is difficult for two adults but becomes effectively impossible once babies, toddlers, or preschoolers are added.
What does this have to do with Agile? Everything. A long spontaneous road trip with no planning and a strictly planned long road trip with no room for flexibility are both impossible with a family. Specifically a family with young children.
In our continued attempts to provide the most value to our (internal) customers in the shortest time possible we are always looking at possible improvements to our process. Due to the limitations imposed upon us by the organization as a whole we do not run as a “pure” Agile team. We have borrowed some structure and process from Scrum.
Our processes are something that we do have some ability to change. In a mildly ironic turn of events as I was completing studies for my PSM 1 certification we realized the daily stand-up was not adding value equal to its cost.
