Implications of Self-Empowered Teams

We talk of teams being empowered, but in reality, most teams never reach any level of real empowerment because their focus is on activities over outcomes.

Activities that support the frameworks we implement in the name of Agile become the focus of our day-to-day life. The activity of building and having a backlog of ‘work’ is a metric we typically convey back to leadership on the ‘health’ of a team. So their focus is on creating a deep backlog instead of having a backlog that is filled with strategically aligned outcomes that deliver value.

If a team is truly empowered then they would know how their decisions of what to work align to outcomes that the organization seeks.

Unfortunately, in most organizations, the transparency and alignment of strategy to value is not well known or may not exist at all.

Empowerment is not just Leadership saying, you are empowered, it’s instead about laying a foundation of transparency about what they believe is the most important outcomes that teams can deliver and then providing them the runway to do that through experimentation and empiricism.

A truly empowered organization won’t look anything like the frameworks say it should, because empowerment implies a higher level of independence than the frameworks provide.

With great independence comes great responsibility for everyone involved in ‘Being Agile’.

Empowerment must build trust through the ability to show how you delivered value and that value then being positively leveraged by the organization to sustain and support growth.

Succeeding to Fail in Agile

In an Agile environment everyone needs to understand that ‘being Agile’ is about taking the framework of tools, processes and methodologies and applying them to your specific organizational needs. At Disney where I was part of a group that moved into Agile, our first foray into Agile Discovery and Planning was, well an epic fail. We we didn’t produce any work product that would allow us to enter a Sprint.  We developed a lot of ‘stuff’ but as it was at is it turned out, not the ‘right’ stuff.

But from that initial failure we evaluated what did work (group Discovery) and what didn’t (PO not taking ownership of story development).  From there we were able to begin to understand the ‘what’ that was important and over the course of around six months we developed a pretty solid delivery model that allowed the organization to feel confident in our delivery abilities.

Now, what worked for us at Disney more than likely won’t work for your organization.  The only way to find out is to try something, anything and see how it goes.

If you want to be a virtuosos at any musical instrument you need to practice, hour upon hour of repetition.  Along this long road of preparation you will find some efforts easy, others hard.  You will fail at mastering some part of a technique that just seems so difficult, you feel you will never get past that point and then you will try something else and BAM, you got it.

From our failures comes learning, the type of learning that becomes part of your DNA. Your mind takes over and can put thinking in the background as you play your instrument.

To be great in Agile, your organization has to change its very DNA.  If you want to succeed, you have to fail and you have to fail often and quickly.

You hear that a lot in Agile when we are talking about our test automation, let it fail early and often. We know that fixing issues while still in development is significantly cheaper than fixing them in Production.

Make sure you instill in your organization, management support for succeeding to fail.

Baseball players get into the Hall of Fame for succeeding to fail at a 70% clip, if you bat over .300 for your career you have a good chance of making it to Cooperstown.

As your teams embark on their Agile journey, keep these concepts in mind to ensure you are driving towards success:

• Self-organization – We want this to happen and for teams to be empowered, because they know more than anyone, what the real pain points are to their daily work.  Let them try something to see if it works no matter how crazy you may think it sounds.
• Retrospectives – Make sure that a team that is self organized and is empowered to try new approaches is having regular post Sprint retrospectives.  This continuous inspect and adapt cycle ensures that we are always evaluating what works and what doesn’t.

In the end if things aren’t working - TRY SOMETHING. What do you have to lose?

PMO Role in Agile - Part 2

My initial blog seemed to have some interest judging by the number of views it's received so I'm guessing that it's a topic that many are looking for input on.   So I thought I'd provide some more thoughts as to what a PMOmight  look like in an Agile organization. One of the key things that changes with a traditional Project managed organization is that they must change to one that is Product managed.  What this means is that the organization changes the way that it funds its business by essentially providing Product Owners with Scrum teams that will deliver on their vision for their product.  Given this paradigm, along with the creation of the Scrum Master role, the PMO and subsequent project managers are left outside looking in.

Managing Product driven teams means that you are managing towards outcomes that delivery value over projects that deliver features.

In my previous post I provided some suggestions as to what individual Project Managers could do to make themselves more valuable and productive to their teams.

In this post I will suggest a PMO structure that focuses on the Portfolio view and leaves the operational execution of the roadmap to the Scrum Teams and Product Owner.

For this structure to work the organization needs good Scrum Masters and preferable ones that aren't also individual contributors for their team.

The structure of the PMO will be lighter than you might think is right, but I'll argue that if you have the same number of Scrum Masters and Project Managers you will set up role confusion that will make your entire project management process cumbersome and less productive.

The PMO structure would look something like this:

I think one of the things that a PMO organization needs to be aware of is that their focus is not on control of projects and people but on how teams are performing.

With this structure you have a thinner level of Project Managers who are focused on Program level Product Management (PPM new acryonym anyone?). Your Project Management function becomes one of oversight of Scrum Masters and working closely with Program Managers in other Product groups who probably will have cross org dependencies.  The Program Manager level in this structure is more about working to ensure that teams are working on the right things based upon the Product Roadmap and escalating when individual team priorities become out of line with the overal corporate product objectives.

What we want with a PMO is confidence and how we do that historically is to place controls, gateways and processes designed to show that teams are checking off boxes that we believe represent how a successful project should unfold (aka Project Governance)

How we do that in an Agile organization is to ensure that our teams we have a clear Product roadmap, that we are performing effective planning both in the areas of Product Discovery and Release Planning, that teams are provided time to review and estimate the work that they are being asked to commit to AND ensure that teams perform continual inspect and adapt cycles via Retrospectives.

If teams are allowed to form into solid high performing teams what you get from that is an organization that learns how to estimate accurately, which leads to consistent velocity which in turns leads to predictability....which is what we in the PMO (and Sr Management) are looking for, simple right?

What I learned years ago from my Project Management days is that Agile actually provides you with much more visibility and transparency about what is happening with your commitments,  providing you as the stewards of the product an ability to have fact based conversations with stakeholders who rarely understand the complexity of what they are asking for.

Agile Certifications - Why they aren't neccessary

Agile started many years ago with some basic (note I do not say simple) concepts related to how we should work together to build better software products.  Though I struggle with the notion that mere communication among individuals can deliver quality software, it can provide a product that is closer in alignment with the product owner's vision. I remember as Agile unfolded there was a debate on whether we needed things such as certifications.  I recall the argument that the very process of creating certifications for things such as Scrum would defeat the very benefits that the Agile manifesto was attempting to address.

Now many years into the manifesto I have to say that these certifications have brought an element of rigor that 'can' be beneficial but I think often stifle the creativity that can come out of Agile teamwork.  Certifications do not make you a great Scrum Master nor a Product Owner, they merely convey that you have taken a 1-2 day class that has provided you with the  evolved standards that Scrum has been defined to be.

I've been involved in a number of Agile transformations along with working in already high performing agile organizations and none of them are alike.  One thing I have taken  away is that teams who are provided space to try new things often find creative ways to solve the unique challenges they face.

As someone who started in Agile from the project management perspective I quickly realized that I was not your standard project manager who managed against a project plan, happily disconnected from my team.  No I was always learning, asking questions, it is how I went from a project manager into QA, because I took an active role in being in helping my team deliver great software.  Through out it all I was most focused on getting feedback from my team in order to improve our processes.

In those early days there were no certifications, we just took the concepts and did what worked and continued to evaluate how and what we did.  With certifications there is almost a cookie cutter approach to engaging Agile that I don't believe was the intent of the original writers of the manifesto.

Scrum and the processes it provides are extremely important, I'm not saying that these don't bring value.  What I am saying is that you don't need certifications in order to be good at Agile and Scrum.

I always tell my teams, Agile isn't easy, it will highlight every weakness in your delivery process and force you to ask hard questions about how much the organization is committed to changing the way they deliver a product.  Having a Scrum Master or Product Owner certification does not help in these situations.  What does help is working with an experienced Agile coach who has been in the trenches, who is experienced in the demands that Agile and the transformation present.

As an organization looking to adopt Agile, getting certifications for your team is not a requirement to working the concepts that so many teams use to be successful in Agile.  Don't let certifying your team be a precursor to moving toward Agile.  At one organization I worked at we took this approach and ultimately it wasn't necessary as the majority of the people who were 'certified' were not involved in working in daily Scrum team activities.

An experienced coach will be able to guide you through how to work as a team, manage communication and change the way that you deliver software products and your organization.

And yes I have several certifications including CPO and CSM and know that these are now almost standard requirements for anyone wanting to work in an Agile environment However if you are just starting Agile don't assume that someone who has been certified is necessarily an experienced practioner.  When looking for help in adopting Agile you should look for someone who has been involved in more than 5 different Agile implementations or organizations, perspective is worth it's weight in gold.

Agile, Change and the things we can do

We home school our children and a few years ago my wife decided to utilize stories and a Kanban board to manage the kids work flow every day. Doing this provided her the ability to build a backlog of work tasks that our children were going to work on (no we didn't have them perform estimations or commitments :) )  Each day she puts up the work that they need to complete in the Not Started column and then the kids can decide which ones that they want to work on and pull the ticket into the In Progress column.

Once they are done with a ticket my wife reviews the work and if accepted moves the ticket to Accepted.  This approach provided our kids with some level of control over their work flow and also an understanding that they weren't done until Mom signed off on their work.  This way of managing their work provide them visibility to how much is left for the day and more importantly the topics that cause them more trouble.

Now that my daughter is working on her first business/website (she's 13) we are using an Agile Discovery process where we are building a User Story backlog (she's learning VOC) and developing low-fi wireframes (she's learning design) for her website where she will be selling her customized jewelry made out of recycled products, photography of the animals she has seen across the country and raising awareness of animal conservation.  She's now comfortable with an Agile process because we laid the groundwork during school.  I think in many ways teachers could utilize this process which would provide visibility to high performing individuals and those that are struggling.  Taking a page from Scrum perhaps the high performing individuals can provide support to the ones that may be struggling, just like we would expect our Scrum teams to do when someone is struggling with a particularly gnarly code problem.

Agile is most commonly associated with Software Development, but really the iterative continuous improvement concepts apply to anything you want to focus on.

Agile can be applied to changing your habits.  For example if you want to lose weight, write an Epic stating that value of losing weight, then write several thematic user stories with your intermediate goals and then write stories for your sprints with specific activities you need to accomplish (exercise, etc...) put it on the wall for your Kanban tracking.  If necessary have a standup with people who are supporting you so you can report on your progress, impediments (Ben and Jerry's is right next to my office...)

An underlying principle of Agile is the need to change behavior, not just of the teams building your product but those that want them built.  You can't have a smooth running organization if you don't address the intrinsic  behavior of people in general.  Agile can provide the framework for helping make this change by providing a shared language.

When we work in an organization we may think we are all working towards an end goal (ie making great products, making money, etc...) but as soon as an organization begins to grow people who don't know each other and who may have no shared experiences need to start communicating.

I recently completed McCarthy's Core Protocol training  and one of the things I came away from it was that getting people to have a shared framework of communication is the most important thing that high performing teams and organizations should focus on, the rest will come as a result of this effort.  If you deliver this you deliver the ability for these teams to produce great product anywhere/anytime.

Think about it this way - We are all organic systems, who behave based upon the experiences that we take in over our life time.  Since no two humans are organically the same ( not even your own family) we end up with an ineffective communication driven by our life experiences and trained responses.

Core Protocols and in my mind Agile, provide a framework to establish a common language, just as we do with disparate technical systems (isn't that what a service based architecture is all about?), we write code that provides a common communication protocol between them, removing the impediment their different languages pose to having them communication effectively.

As you begin to start to adopt Agile understand that though the practices you read about, such a Release Planning, etc... are extremely important, the need to provide your teams and organizations a shared communication framework are equally important to long-term success.

Rear View Mirrors aka Mater Vision (Retrospective Habits for Agile Teams)

One of my favorite movies is Cars and specifically the character Mater, rusty and crusty but full of humorous and unintended sage advice.

During one point in the movie, Mater starts driving in reverse, on the road, off the road and Lightening McQueen is very impressed and asks Mater how he drives so well and his answer was, Rear View Mirrors to which he adds I don't need to know where I'm going if I already know where I been.

I started thinking about how this applies to high functioning Agile teams and their ability to provide predictability to their organizations.

More specifically I'm talking about how Retrospectives act as our rear view mirrors providing us with key visibility to where we were just at and an opportunity to reflect on where we want to go.

As an Agile team we constantly reflect (via Retrospectives) on where we were just at so that where we are going is incrementally improved, much like Mater and his rear view mirrors.  He's constantly reflecting on where he's been such that he's already where he needs to be before he gets there...

For organizations that are starting to adopt Agile ensuring that your teams utilize the Retrospective process is key to seeing the types of productivity improvements that Agile can and should deliver.

Retrospectives need to be both a no holds barred conversation about what did and did not work, but the team needs to ensure that it's also a safe place in which to talk about the issues that keep us from being really successful.  As a manager or management team you need to back away from the team and give them room to organize themselves.  As I've said before if a team feels empowered and is clear on the vision of the organization they are capable of solving both team and organizational issues that you didn't think were easily solved.

Traits and habits of good Retrospectives are actually very simple:

1. Have it consistently after each iteration.
2. Hold the Retrospective right after your demo while all of the iteration context and issues are fresh in your mind.
3. Each Retrospective should start with review of any action items from the previous sprint.
   1. Scrum Master - Ensure that this happens as this is the key to having the team feel like the issues that are causing problems are actually being addressed.
   2. Scrum Team - You need to commit to addressing the action items identified in a Sprint to ensure that you are applying continuous improvement to your teams processes.
4. Working Agreements - The team needs to have a set of agreements by which their Retrospective will be run, follow these agreements, which should include:
   1. Respect your team members - Allow them to call you out if necessary if you were in fact a blocker (I have been and no it's not nice to hear that, but your teammates are relying on you to make sure that they are successful.)
   2. Attack the problem not the person - This is key, you all want to be successful, don't take things personally, ask questions and come up with solutions that might work.
   3. Understand that not every idea you have will make things better, be prepared to fail.
5. Keep the Retrospective to the members of the Team that are responsible for delivering the work (aka Individual Contributors).  Managers and Stakeholders should not attend.  As a Scrum Master you may have to tactfully address this if these individuals want to attend.
6. Relax, we aren't trying to solve world peace.

Continuous Improvement leads to predictable velocity providing you with the ability to be like Mater.