Agile for Sale

It took 15 years to run under the bridge of the big Enterprises, but Agile is now the only thing Enterprises want to talk about. People that until now were labeled as "They don't understand how real business runs!" are now being mentioned as "Listen to what they're talking about!".  Organizations and individual consultants that until now were promoting traditional methods and leadership techniques, are now switching to the Agile ones and are raising  all their sails to catch the wind and get ahead of Agile as quick as possible.

They are using old skills to gain new horizons. You can't direct the wind but you can adjust your sails

 

In the last 15 years, Agile has been molded in so many ways, with so many names, decorated with so many certifications and promoted by a lot of fake "practitioners". Agile has become something that can be bought, rented, used to hide, patched, washed out, ironed well, thrown away, replaced, upgraded, accessorized, kept on shelf, used for "special occasions" and framed as an achievement.

Now, Agile is for sale just like any item on a store. 

 And it can't be any other way. Once it proves that is successful, everyone wants a piece of it. And when it comes easy (with training and  certification that are 100% guarantied to pass), when it comes open and non precisely prescriptive (so that anyone can come up with their personal interpretations), when it comes as a medication that tastes awful but can be covered in a thick layer of sugar.. it makes it easy to sell it to anyone, from big leaders to "downstream resources".

Agile has become like a T-shirt, that can be sold on every store on a mall, that can come in any size you want, any color you want, with any printing you want and any price you want. 

Newcomers to Agile are confused. Not to be blamed.They fall for the big shiny signs and the stores that offer "1 stop shop for everything you need". 

The problem? Authenticity, the core and craftsmanship are being lost. Real agile has become the small corner store that big companies are trying to put out of business.

Meanwhile, more methods, frameworks, certified people and experts keep being generated every day. They all promise something unique that can't be found somewhere else. Packages and deals get more lucrative and CIOs/CTOs are the targets that everyone wants to hit for a big ROI.

There's no need to be emotional about this, but jokes are always welcome to improve the quality of life with laughs. As per the pure Agile spirit, everyone is learning. New practitioners are learning and they are trying to find a place to do so. New organizations to Agile are also learning and based on the choices they make they are learning on different paces. Some of the people with expertise and good knowledge on Agile are learning marketing skills so that they can make more money (they are like those big brands that sell high quality and branded products with a high price tag). Some other people with expertise that are not interested on new marketing skills are working to bring more success stories about Agile so that all of the above can continue on the path they have started. Success sells and someone needs to showcase it. 

So let's all do our part on this new world. At the end we all want different things and that's why the World is a beautiful place. There is plenty for all. 

But if you want to learn the real Agile, you better look at those success-story-makers!

How can we get people to have an experimental mindset?

Last week was Agile 2015 and I couldn't miss it! As Jake Calabrese says, it is "summer camp" for agile adults

On Thursday, I had my session where I co presented with Cheezy (Jeff Morgan) : What's my MVP?
I am particularly passionate about the art of building products. I mean it, it is an art. There is a variety of variables to consider and a lot of experimentation to run in order to come up with the product we want and the roadmap to evolve it.
I enjoyed the presentation and the discussion. There was only one question that I felt I didn't address as I would have wanted to, so I will do it now.
Question was from Stephen and, it came after I said something around the need for an experimental mindset in an organization. He asked "How can we get people to have an experimental mindset?" I made fun saying "We force them, we beat them up :)... NOOOO.. requires some coaching". Cheezy also added "Slowwww". Now there is more to add here.

I don't think MVP is an agile/lean transformation tool. For people that do not have the experimental mindset, we have a bigger problem than getting them to figure out the MVP.

They are not ready for this.
First, they need to go through the path of dealing with failing and learning from it, need to get into the incremental and iterative way of working, need to learn how to break work into smaller chunks, need to understand how to focus to a user(small group) at a time, need to learn how to take feedback as a gift not as a punishment, and most of all, need to be comfortable with delivering often.

Can someone have an experimental mindset without knowing about the long list above?
Maybe, but I doubt it. You might not know the names and the order of the things above, but you might do them naturally. You might not be aware of agile development but you are on environments that support this way of working without calling it Agile.

So to get someone that doesn't have experimental mindset to work with you on figuring out the MVP, it will take some time and it will take some coaching/mentoring/hands on/pairing with someone that has this mindset. And it will not happen over night.

Story Map upfront planning?...It depends!

I will start with two disclaimers, just to set the stage:
Disclaimer 1: This is not a blog about "You're right, I'm wrong" or the other way around. I might refer to people I trust their agile maturity. I do not think I am a beginner myself. So we are all discussing in a decent-high maturity level.
Disclaimer 2: This blog is in the context of a large organization in love with Agile principles, where a large change is starting as a new project, team and sponsors not mature in Agile. My focus is more on the Product building point of view, not Project management.

I have been working at my client for over 2 years now, with different teams, facing different issues. I am pleased with how this organization has moved forward and improved with Agile principles. Yesterday, one of the teams that has regular get together coaching sessions, asked to discuss about Story Mapping.

Kit-Kat break:
2 years ago, when I first started in this organization, they were told "Go Agile!" with almost no hands-on experience. On top of that, the groups around the delivery team were struggling with Agile as well. The quarterly budgeting was a new concept, not proven and not exercised in quarterly fashion either. Business was put on the Product Owner chair without understanding what that meant. And yet, the team had to deliver a huge change in an Agile way!
As the coach for this team, I proposed to use Story Mapping as a tool to eliminate BRD writing-approving-updating process. I also used Story Mapping to get everyone on the same page, understanding the Why and the What of the change, bringing Business and IT on the same page and have a maturity on the decision making. The team identified to participate in Story Mapping exercise was 45 people, representing 43 systems that were being affected by this change. It took about 2 weeks to prepare the Story Map, create a strategy on MVP delivery, discuss with sponsors on the value delivered on each MVP, make any adjustments/changes, really high level sizing of the work, and get ready to start Sprint 1. If interested I can break all this down on what was done every day. But I don't think that is needed. The goal was to have a backlog that we all agreed will be updated constantly, to have a roadmap on how this product will evolve starting with the first MVP, to get the team to feel comfortable owning this work and delivering high quality.
(*Clarification added after some people read this and asked: Not all 45 people stayed for 2 weeks to work on this Story Map. 45 people worked together for first 3 days. For the rest of the time, there were mostly core people from the 3 bigger systems that were being affected. All 45 were on standby for any question that the core group might have had during that 2 week period.)

Outside of this organization, I have used Story Mapping multiple times, in workshops or with real projects being delivered over a weekend by volunteers (GiveCamp examples). On these setups, Story Mapping has been from 15 min to max 30 minutes. Teams were smaller, work had a smaller focus and Product Owners had more decision making power.

I want to continue below here with the large organization example, as per my second disclaimer.
Kit-Kat break over.

Yesterday, on the presentation I did about Story Mapping, I took them through the steps on how to create the Story Map explaining the thinking behind, explaining the goal and showing some examples on how to break a Goal to Activities and Stories and then slice them to create a small size MVP. Focused on the fact that now MVP 1 is our closest target, without losing track of the big picture with the other MVPs on the roadmap. I also used my example from 2 years ago and mentioned 2 weeks period of time used. One of the people on the call made the comment that Story Mapping seems like a big upfront planning.
On one side, I was happy to hear that! This means that there are areas in this organization that are really getting quickly through the process of creating MVPs and have created a good relationship with their sponsors and are able to pivot without push backs. That is where we want to be and I was glad to hear that.
On the other side, he also made a comment saying "Well, we all know that what we present at the beginning is going to change and we will need more money and more time down the road!".

I was not comfortable with that.
I believe in being open, transparent, working smart and hard at the same time. Over and over I hear examples where teams have gone to Sprint 1 without a clue on what they are doing. 4 Sprints down the road they use agile as an excuse when sponsors are confused and have no idea what is being demo-ed to them. Complains about sponsors not getting this Agile thing begin and sponsors start micro-managing the team because they lost trust. To sponsors, the team is a bunch of cowboys running across the town, making a big mess and fixing nothing.

As a coach, I would like to create a team that looks like Clint Eastwood when riding the horse across the town. Be confident, be sharp and quick, armed, with horses that are strong and healthy. I want my team to be a group of craftsmen in IT delivery AND in Product strategy. Craftsmanship is not done quick.

If the team doesn't take the right time to look at the work ahead, there is no point on getting them to start running fast on the wrong path. Slowing down a bit, makes you move much faster after.

Is 2 weeks a lot? I still think those 2 weeks were necessary for that team, for that project, on that context. The Story Map kept being adjusted and updated while the team was working and delivering. Just like any backlog, it was groomed and prioritized. At the end of the first MVP, I asked the Dev lead (he was really skeptical that  agile would work on that project):
Me- So what do you think about Agile now?
L- Are you kidding me? We would be still writing documentations by now. And look at us, we have first release in Production with only 2 small issues!

Is 2 weeks a lot in other environments and teams? Maybe ..Yes... especially for small changes or small companies. I am hearing 2 hours to 1 day timeboxing. If I only had the GiveCamp experience, I would say: Are you crazy? We delivered a whole website in 1 day!!

So: It depends!

At the end, the whole Twitter conversation I started, was with the Product building in mind. The timing discussions made it more like a Project management issue. I wanted to get the pulse on the Story Mapping as a tool for product roadmap, but then it started looking like analysis-paralysis.

That was not my original point of view.

If there is information that we have, let's put it on the map and VISUALIZE IT! If there is information we don't have but we need, we found an area where we need to do some discovery/spikes/POC. All and all, Story Mapping visualizes what user/sponsor says and asks for. It visualizes it in a way that you can read it from any level, and go as deep as you want to (if it helps/is necessary). It helps everyone to get on the same page quickly with user's needs, with the story this change is bringing, with the impact this change will make on every step of user's experience. Limiting how deep you go under each goal, or saying "the 1 day timebox is over so we should have enough info now" do not convince me. Why should we do that?
Creating a thin slice and getting to your first MVP is not an easy job. Sometimes that sticky at the end of the pile, can make a big difference when the team sees it there and has the option to put it on the first MVP.

And most of all, this is an exercise that creates a great relationship within the team. While everyone participates, a lot of trust and openness is created. A lot of knowledge is transferred and as a team, you end up connecting, collaborating and having fun.

The "how" part on delivering this work is where project management begins, and where I want to stop. It is a completely different conversation from what I wanted to have. But if I have to say something, I don't think the team should do *only* Story Mapping. I mentioned spikes and POCs, but on the same time you want to also have open conversations with sponsors that might not be all the time in the same room, but still want to know where their money is being invested.

I still hope Jeff Patton sends me his number and have a call with him :)
   

Bring in the Communication team!

I am recently assigned to work on a project that in reality is a program. It is so big that it has its own PMO, Change Management team and Org Chart. The team keeps growing to the point that 4 team rooms were not enough so we had to move to a new location and we have a team floor.
As a coach that joined team late in the project, one change I decided to make was to collocate IT, Business and Vendors. They were all sitting in different areas. Close to each-other, but not together. In my mind, a small change like this, would make a big impact on how the information will flow and how the collaboration will improve. So I suggested that when we move to the new place, we re-arrange the seats so we create these cross-functional and cross-vendor areas on the floor. It was taken in a positive way and I heard some PM and some Directors supporting this idea.
Due to the higher levels involved on this, I was not part of the move-plan. So patiently, I waited to see if my suggestion was considered. On the moving day, we moved to our desks and I noticed who the clear line was put between the Business side and the IT side. The line is actually right at the end of my desk. It is a narrow path for people to move and then there is a desk where someone from Business is sitting.

I decided to call this narrow path "Checkpoint Charlie"

Through some Lunch&Learn sessions I have been running, I created some connections with the Change Management team. They invited me to a meeting with them, and one of their concerns was that they didn't know the scale of the change this project is bring on the IT side. They had a good knowledge on how business was changing, what areas needed more training, etc. Nothing on IT.
So I asked them what was their plan, their next step. And they looked and me and said "We hope you can help us connect with IT. We are creating communication emails, internal websites and have weekly meeting to improve this".

I am not against having emails that go to everyone on the team and gives everyone some updates on what is going on around, ways to thank and support each-other, any baby's born, any events coming up...etc.
But I am against using these emails as the transportation vehicle of a message from Business to IT.

I told them about my idea of changing how we are sitting now. How we can organize the areas where Business and IT are sitting close together. They looked at me baffled. That was a decision made by PMO and executed diligently by an assistant admin. So diligently, that when I suggested the idea of teams being created by "Who do we need to make this work stream successful?" on an empty wall where everyone could write the names of the valuable people, she started screaming to people and telling them that SHE was the one to make that decision!

I asked the communication team what was their goal. They mentioned that the main thing was training and readiness, but communication was a big concern. Here we have a group of people (some of them contractors that are not cheap at all) that instead of helping with what brings value to the delivery, help with moving messages back and forth. All because the walls between Business and IT are still guarded by PMO.

Environment and the Desire to work

In the last 2-3 years in my career, I have been working mainly as an Agile coach in organizations that were transforming to some sort of agile delivery framework. This means that the default mindset of working on these organizations has been complex, multilevel, old and in general slow. As an example, it takes about 1 month, 9 people, 80 emails and a couple of form requests, to add a column on a table. As an agile coach, this is where I find inspiration to help and bring a change, improve something and someone's daily job routine.
But it has a toll on me. As an extrovert, I am running out of external energy to feed me and keep me positive. I like to do things. I like to see people working on exciting stuff, being innovative and motivated to come up with the best idea possible. I like to be pushed to my limits and test my creativity, my energy, my skills and eventually, keep me energized. None of these has been at the right dosage for me recently.
And then I heard of "Give camp". A friend of mine is part of this and mentioned it to me. It is practically a bunch of developers, project managers, UX designers, copywriters, coordinators, etc that volunteer a weekend to build digital solutions for non-profit organizations. I thought that is a very cool opportunity for geeks to shine and show how valuable they are! So I registered.

6 people built a website from scratch (Wordpress) over the weekend (Friday evening till Sunday afternoon)!! There were some tables and columns created, but didn't take nearly as long as I have been seeing lately. On top of that, we also had time to have a break and go visit a submarine that was right beside the venue. 2 developers, 2 product owners (from the non-profit organization), 1 project manager and then a part time copywriter and a part time designer. We worked, we laughed, we made friends, we discussed and we loved what we did! It was all for a good cause at the end. Go see it : http://www.lakewoodalive.com/

What this weekend reminded me, was the power of a small team that has the right access to the right tools and that works closely together. "Small animals move faster than big ones". This is so important when you think about delivering often and small batches. One of the core concepts of Agile delivery. Any other person added to that team, would have brought more delays than help. Any more process than a white board with stickies moving from ToDo to Done would have been adding delays and annoyance. There were a couple of times when we needed "specialists" like someone that understood well the hosting tricks or working on htaccess redirects. We asked them to drop by our desk for a while, help up, thank them and off they went. 2 Product owners were constantly being asked to prioritize the backlog and that helped keeping everyone on track and focused. At the end, they would take a look at what was done and give the ok to move the sticky to Done or not.

Why scale agile? It is so beautiful when it's small, fast, lean and valuable.
I came back to work on Monday and looked at my emails waiting for someone that waited for someone to approve someone to push a button. I didn't know these people. They were all remote, and they were called "resources assigned to my project". I do not believe that these people had bad intentions and wanted to delay our delivery. It is the extras added in the process, in the necessary steps to accomplish a task, in the number of people that had to be involved to accomplish that task, in the managers that had to be added for approvals, and so on and so on. It is the big silos created with a narrow focus and all the paper work that surrounds work intake and work delivered by them. It is lack of motivation that comes when working on slow moving and sometime bureaucratic environments.

Can we de-scale corporations to small groups? Like the planes that move together and make a lot of fun air-tricks or combat (same goal) but are all independent units with a clear purpose and able to deliver fast.

 

  

Measure me, Please!!

I was asked to run a training for a small group of new Product Owners. They were about to be part of a new project starting soon. The team and the Scrum Master have worked together before, but with other Product Owners. So they asked me to help these new Product Owners to understand some context on Agile, Scrum and what is the role of the Product Owner.
I have done this kind of training multiple times before so didn't need to do anything specific. I loved the fact that they came from a Lean mindset and some of the concepts that usually take time to discuss, went very smooth with them. Loved it!! I even asked them if I could shadow them for a day and see what they do. Their titles were "Manager of Continuous Improvement team", how cool is that!! (ok, there is something wrong with me).
Part of the training is also an exercise that I run with them where I take a real project and I walk them through Intake process and then building the Story Map together. This means that they start by explaining me the project, the goal, the benefits, etc. This project was about setting ways to track and measure people's activities in order to use it for their performance review.
All of a sudden, all the joy I had built up while discussing with them about the Lean mindset and Agile way of working,  was all shuttered  and broken into little tiny pieces. While they kept explaining to me how they wanted to measure 100% people usage, and how they wanted to measure if in a team of two people one of them did 40% of work and the other 60% of it, my mind was spinning on a different dimension. I so wanted to stop them and say "But guys, they are people, not machines! Why would you want to measure people like this? What kind of performance are you measuring like this? What kind of behavior do you expect to see after you do this? You even want to spent a lot of money and have this project to build a system that will measure this!..." I think I started boiling inside and was coming up with ways to get them to stop this monster project. So I asked if in a higher level, was this the most important project to invest? Maybe this team can be used to build something more useful to business needs. And they told me that even higher level managers prioritized this project to High and they want to see it done. I think my face was changing shape and color because at one point they stopped and they were looking at me with a confused look.

So I asked "Have you received any feedback from your end users on this product? We need them to be involved". And the answer made me drop my jaw "They asked for this! We prioritized this high because they have been asking us for a long time about this!"
Everything dear to me about people management, all Management 3.0 ideas, everything that Deming has said, all models about Trust, team work, team health...everything went for a moment down the drain! Then I had the opposite idea: Is this company to a level of operation where they have done all the things I had in mind and now they have found other revolutionary ways to work with people?!!

And then something came in my mind that helped me to get back to chill mode again.

CONTEXT!! Yes, Context is truly everything!
I had forgotten that the people that would be measured by this system were not knowledge workers. They were people that worked in shifts at a distribution center. Very manual work, with scheduled breaks and an agreement on the time they would take for a coffee/smoke break. Even their titles are the ones I have heard before from Amazon, such as "pickers", "shippers", "people on the floor", etc. So Taylor's theory still works for them. They go to "performance review" meetings without knowing how they were being measured. They all moved boxes from a trailer to the conveyer or vice-versa. They all get to work at the beginning of the shift and they all leave when the ear-piercing buzzer goes off. So they were asking their managers "What does it mean to be a good employee? How do you know who is a high performer and who is not? Why X is being told is a good employee when he takes a lot of coffee breaks?" And managers asked for help to create a system on how to give sense to what these people do, set up a way to measure the lead time for a certain process based on some parameters, and then make this visible to everyone so they know what do they need to do in order to get a bonus!

After this, I started collaborating with them on creating the Story map and other conversations related. At the end of the day I was still thinking the ethical side of what I did today, and at the end I think I did the right thing and helped some people that wanted to solve a good problem. I just had to move myself into a different environment from where I am usually used to work, consider different parameters and inputs, looking to solve a problem from a different dimension.

If you read this, and you are an Agile coach, I would love to hear your feedback.