Wednesday, January 29, 2014

Introspective: Follow-up to Kaizen Questions

I recently wrote a blog post about Asking Kaizen Questions. I saw an example of what may be considered Kaizen Questions on our KAT Board the other day. Let me explain.

We have a large glass board furnished with neon dry erase markers on one of our hallway walls. I don't know what it's official name is, but I call it the KAT Board because it is periodically erased and seeded with one or more questions from our CIO, Karenann Terrell (or KAT for short). Here's the question she posed earlier this month:

"What do you hope to accomplish in 2014?" -- KAT
Once the question is posed, everyone is encouraged to grab markers and write their responses. The other day I walked by and saw this:

"Excellence always. If not excellence, what? If not excellence now, when?"
I saw that and thought, "What excellent examples of Kaizen questions!" They provided a challenge to the status quo and some sense of urgency. I liked it, but I thought it was missing something. I'll come back to that.

Over the past week, I've seen varying levels of engagement at the personal, team, and domain levels, particularly with regard to Agile. As thrilling and exciting as it is to see someone pick Agile up and own it, it is equally frustrating to see someone wait for the organization to transform around them before they decide to act. To take it a step further, it is necessary for each person within a company to own the company's success. If they don't feel that they have a voice or don't see the importance of using that voice, they will eventually outlive their usefulness. Companies with engaged and empowered associates will pass up those whose employees are just there to take orders and get a paycheck.

So I went back to the board and added another question to help deepen both the sense of urgency and personal accountability.

"If not us, who?"

Friday, January 24, 2014

A(nother) Response to SAFe Criticisms: Part 3

Full Disclosure: I am a certified Scaled Agile Framework (SAFe) Program Consultant (SPC).

In the first part of this series, I explained my intent behind answering some of the criticism for SAFe and asked for concerns that you would like to see addressed. I haven’t received any direct feedback, but the offer still stands. In the meantime, I’m going to dive into some of the more common criticisms I’ve seen already published. I’ll try to focus on one concern or small group of related concerns per blog post.

HIP Sprints
One criticism that’s prevalent among SAFe’s detractors is the inclusion of the HIP Sprint on the Big Picture. This is another case of SAFe trying to accommodate reality for organizations new to Agile. HIP, by the way, stands for “Hardening | Innovation | Planning”. It definitely gives the vibe of “Waterfalling the Sprints” and deserves our attention.

Hardening
Hardening should, in my honest opinion, be done away with as soon as humanly possible. However, if you’re brand new to Agile and have not yet built up your technical practices and hardware, releasing to Production without a hardening period is a bad idea.

SAFe does a good job of outlining what may be appropriate hardening activities versus those that could/should be done sooner. This is a good resource for new teams to get rid of hardening. Teams should focus first on getting activities that should definitely be done before hardening included in their Sprint Definition of Done. Then they move on to those that could be done sooner out of hardening. Eventually, they should aim to have their Release Definition of Done match their Sprint Definition of Done. At this point they could, potentially, go to Production with the completion of each User Story, which is just a hop, skip, and a jump away from a continuous delivery team.

Innovation
I know, I know, having an “Innovation Sprint” is like having a “Kaizen event”. And yet, we hold Retrospectives as an opportunity to focus on improvement that should, in theory, be continuous. If your company does not support a culture of innovation then no framework will magically change that. However, if you have a team that has managed to eliminate hardening activities, they should be rewarded with a Sprint of unfettered innovation. Give them a couple of weeks to do what they want and they will surprise you with how much they accomplish! Heck, it may even help to transform the company’s culture to one that embraces innovation.

Planning
This aspect of “HIP” tends to have the least resistance as Planning is well-recognized as a fundamental component of successful Agile organizations. The final Sprint of the PSI should include the planning activities that will prepare the Agile Release Train for the upcoming PSI. These include the Solution Demo (PSI Review), Inspect & Adapt Workshop (PSI Retrospective), and PSI Planning (PSI Planning).

Most ARTs will get these activities done in the last 2-3 days of the PSI. The timing and duration are flexible, but the activities are essential, especially for new Agile teams. This may not make sense for continuous delivery teams, but neither do any of the other time-boxed meetings that provide the structure for time-based commitment approaches (a la Scrum).

Thoughts?
Given my experience with new Agile teams, the HIP Sprint is a powerful tool. Without it, making the transition to Agile would be near-impossible. Is it a mature Agile practice? No, of course not. But is it better than continuing with Waterfall until the teams magically reach a state where they can do Agile without a HIP Sprint? Most definitely. That’s what I think, anyway.

Thursday, January 23, 2014

Asking Kaizen Questions

If you've read my previous material you already know that I'm a big proponent of questioning everything - getting to the "Why?" of what we do. What I've realized lately is that simply asking "Why?", though a good start, is not as effective as asking the right "Why?".

We get better by asking questions and acting on the answers. The better the questions, the better the answers. I'm going to refer to the right kind of "Why?" question as Kaizen questions (full disclosure: I don't know if this is already a thing or not, but a basic Google search tells me it's at least not widely used).

Let me give you an example. One question I get a lot from those resistant to Agile is, "Why should I give up Waterfall?" or "Waterfall's always worked for me; why should I stop?" A slightly more open-minded derivative to this question is, "Why should I try Agile?" If we were to take the Kaizen approach and recognize that perfection is unattainable but improvement is always possible, we would ask, "Why should I continue using Waterfall?" or "What other approaches could I use to deliver quality and value to my customers?"

The Kaizen Question doesn't ask how well the current approach is working because there is an inherent understanding that it could be better. It focuses only on the alternatives to what is currently being done. This type of question is crucial for those adopting Agile to ask themselves as they transition. Otherwise, they risk simply moving from a poor status quo to a better status quo.

If you move to Scrum because you asked yourself, "Why should I try Scrum?" then you are more likely to stick with Scrum and never try something new than if you'd started your journey by asking, "Why should I stick with what I'm currently using?" Do you see the distinction?

I would hope that those who try Scrum eventually adopt a Kaizen mindset and continue to evolve regardless of what question originally got them there. Unfortunately, I have seen too many teams move to Scrum, settle in, and fight against later suggestions of Kanban, DevOps, and other emerging practices and processes. The way I see it, any status quo is a bad status quo and should, therefore, always be challenged. What do you think?

Wednesday, January 22, 2014

Introspective: Max allowed BMI at the Gym

As I've mentioned before, I'm overweight and have been for the majority of my life. I've been trying to change my habits and behaviors to foster increased health in hopes of lowering my BMI (Body Mass Index). One of the behaviors that I'm trying to make a habit is attending the gym regularly.

I have a friend that I usually work out with, and we've had conversations before about how non-judgmental most people at the gym are (at least at my gym). We've talked about how detrimental it would be to someone's health to feel unwelcome at the gym exactly because they are overweight and needed it more than those who are already fit. What good would a gym be if it had a maximum allowed BMI required for admittance?

Gyms want overweight people to go to the gym so that they can improve their quality and quantity of life. They know that not everyone who signs up will show up, and they know that not everyone who shows up will attain the same results. That doesn't stop them from doing everything they can to provide options and incentives for people to get the most out of their membership. Gyms would love for everyone to get down to a certain BMI or PBF (Percent Body Fat) and increase their lean muscle mass and stamina. Yet they also celebrate with those who are still overweight but have manage to get off of half their blood pressure medications. It's about developing a mindset and behaviors that help people trend towards greater health.

One thing that really bothers me is when "Pure Agilists" declare that you must be doing certain things or following certain methodologies or frameworks to be considered Agile. They further condemn any organization that's not operating under their gold standard of Agile. Some examples I've heard recently include: "If you have a hardening Sprint then you're not Agile"; "If you estimate in hours then you're not Agile"; "If your Scrum Masters aren't dedicated then you're not Agile"; "If your customers can't get involved daily with the team then you're not Agile"; "If your approach isn't endorsed by one of the original Manifesto signatories then you're not Agile"; etc.

As an Agile Coach, I have in my mind what I think an "ideal" Agile team looks like. Just as a team should have a Product Vision and a Technical Vision that guide the team's plans, they should have an Agile Vision to help guide their practices. Mine Vision is basically a flat organization of self-organized teams that are running DevOps using Kanban or something similar. They leverage SOA and have near-perfect APIs, making dependency management trivial. Production releases occur as frequently as new functionality is developed with zero defects slipping to production and high levels of customer delight. The teams are like families and there is no overtime.

Now I'd like you to take a stab at what my teams actually look like. Spoilers: it's not what I just described. It is impossible for an organization that is entrenched in heavyweight policies, Waterfall approaches, and a Command-and-Control management style to up an become "Pure Agile" one morning. It's too painful to succeed. What they can do is establish an Agile mentality and start making incremental changes. As they cut waste and increase value, they'll find themselves more and more resembling an ideal Agile organization.

"Scrum...but" gets a lot of flack, but I'd rather work with a "Scrum...but" team that's trying to continuously improve than a Waterfall team that thinks it's got it figured out. There is not maximum allowed waste cutoff for teams to start trying to improve. Those who promote Agile approaches need to be more open-minded about what is and isn't "permissible" for an organization that's trying to adopt Agile.

I had the opportunity to present on Agile to the local PMI chapter last night. For many of them, it was their introduction to Agile. If I'd have told them they had to go all or nothing, they would have shut down. My focus was on the Manifesto and its Principles, then showing them just how many Agile tools are at their disposal. I told them to respect reality, learn what's available, and continuously improve. Isn't that what Agile is really all about?

I know this is probably going to rustle some jimmies, and that's okay; if your jimmies are rustled, let me know why. What do you not agree with? How am I wrong? I don't claim perfection, and I'd love to learn from your perspectives.

Tuesday, January 21, 2014

A(nother) Response to SAFe Criticisms: Part 2

Full Disclosure: I am a certified Scaled Agile Framework (SAFe) Program Consultant (SPC).

In the first part of this series, I explained my intent behind answering some of the criticism for SAFe and asked for concerns that you would like to see addressed. I haven’t received any direct feedback, but the offer still stands. In the meantime, I’m going to dive into some of the more common criticisms I’ve seen already published. I’ll try to focus on one concern or small group of related concerns per blog post.

25% Scrum Masters
Edit: I originally published that "This is something that I have yet to find on the SAFe website but did come up in my SPC training. And I can tell you that it was not well received! If you want to hear about exactly how well it went over, just ask Valerie Santillo. Here’s what I got out of it:"

It has since been pointed out that this guidance is on the main website. I'm not sure if this is a new addition or an oversight on my part. It can be found in the Scrum/Agile Master Abstract in the Details section, under the heading "Sourcing the Role: A Part Time Responsibility".

Accommodating Reality
The truth of the matter is that you can’t always get Scrum Masters that are dedicated to that role. This should absolutely be avoided if possible, especially when working with teams new to Agile. What they’re saying by 25% is that, if you absolutely cannot get someone to be a fully dedicated Scrum Master, you should expect the role to take up about 25% of their time. I’d say that should about cover the administrative aspect and keep the wheels moving, but that’s about it.

Four Teams
A better approach is to make Scrum Master a dedicated role and allow them to work with multiple teams. The 25% recommendation tells me that Scrum Masters can handle at most four teams. Again, if you can avoid it, I would recommend having fewer than 4 teams sharing a Scrum Master. The most I’d personally recommend is two, with a preference to only one. However, this guidance is supposed to accommodate reality, and sometimes you just don’t have enough SMs to go around.

Starting Point
The 25% justification really only works when you’re just starting out and trying to get organizational buy-in. If you can suck it up and make it work well enough then, hopefully, your management will see the benefit a good Scrum Master could make and will make it happen. They’ll remove the part-time role, reduce the number of teams per Scrum Master – anything necessary to continue the improvements the teams have started making. That was actually the case with my first team. They went through their “Sprint 0” and their first two regular Sprints without a dedicated Scrum Master. They were struggling, but they were showing management that they were committed to making Agile work. I was allowed to come in as their Scrum Master – and only as their Scrum Master – to see how it would work. The rest, as they say, is history.

Final Destination
Good Scrum Masters always talk about how it’s their job to work themselves out of a job. If that’s the case, then eventually you’ll have teams that don’t have Scrum Masters. In those cases, there are certain responsibilities or overhead that the Scrum Master took care of which will now fall to the team. In those cases, the overhead work will need to be accounted for. From a Sprint Planning perspective, I think that cutting the velocity to account for 25% of a team member’s time for Scrum Master duties is entirely appropriate.

Thoughts?

That’s my response to the “25% Scrum Master guidance” from the SAFe training. Hopefully I was able to provide some context to show that it’s not as evil as you might have thought. Whether I was successful in addressing this concern or not, I’d like to hear your thoughts on the matter.

Continuing the Series
Part 3: HIP Sprints

Friday, January 17, 2014

A(nother) Response to SAFe Criticisms: Part 1

Full Disclosure: I am a certified Scaled Agile Framework (SAFe) Program Consultant (SPC).

Before you continue reading this somewhat lengthy, multi-part blog post, let me lay out the prerequisites. Well, really just the one. If you are not already at least somewhat familiar with Dean Leffingwell’s Scaled Agile Framework (SAFe) then this post is not going to be as meaningful to you. The official website for SAFe is http://scaledagileframework.com, although there are others out there (Andrew Blain, for example) who have done a good job of explaining what SAFe is.

Last year Dean Leffingwell (and SAFe in general) had a significant presence at Agile2013. In response, Ken Schwaber wrote a provocative blog post entitled “unSAFe at any speed”. What Ken failed to accomplish was to produce criticism that was any more founded than your run-of-the-mill angsty hearsay. He did, however, manage to set off a civil war within the Agile community over whether or not SAFe should be allowed in the Agile club or beaten until silenced or killed. I have been rather surprised at how many “Agilists” have chosen the latter.

Agile has always appealed to my inclusive nature. The goal is outlined in the Agile Manifesto and its 12 Principles. Anything that strives to deliver within the paradigm of the Manifesto and its Principles can be considered Agile. All approaches have strengths and weaknesses, and all approaches focus more on some aspects than others. In the end, though, all approaches are well-intentioned efforts to elevate teams to their potential. I think that’s beautiful, I really do.

A roadblock that has existed for years is that of large organizations who are not already Agile. Getting these behemoths to shift the way they work, much less the way they think, is no easy task. Many have taken the “All or Nothing” approach – either adopt an existing Agile approach in its purest form, wholesale, with no alterations, or surrender yourself to your competition, wither away, and die. Neither of these options is particularly appealing to most of these organizations, so they ignore Agile and continue their status quo.

Along comes Dean Leffingwell and SAFe and, all of the sudden, you have an Agile approach that the organization can use to become Agile. Of course it looks different from the other options currently available, but that’s kind of the point. It aims to establish Agile Principles and Lean Thinking in larger enterprises in increments that are actually realistic. Just as every Scrum team is different, every organization that adopts SAFe does so in its own way. And, just like Scrum, a lot of the implementation details cannot be neatly outlined in a guide or abstract for anyone to pick up and repeat without putting in any of the effort.

The reality of the situation makes the Purists out there really uncomfortable. A lot of criticism has been published. I am going to attempt to address some of this criticism. My intent here is not to get everyone out there to use SAFe. Heck, I don’t even intend for everyone to like it. My intent is to clarify a few misconceptions, first and foremost the one that SAFe is not Agile.


I’ll be publishing my response in multiple parts in order to accomplish this intent. The number of parts depends, at least partially, on you. I want to know what criticisms or misunderstandings of SAFe you would like me to respond to. I would further ask that you communicate with me as a respectful professional (and I’ll do the same). I’ve seen this topic get out of control without ever getting to root cause. Not that I have delusions of grandeur or anything, but I’d like to think that I can help find and address the root cause of these criticisms without it turning into a shouting match. I guess we’ll find out.

Series Posts:
Part 2: 25% Scrum Master
Part 3: HIP Sprints

Wednesday, January 15, 2014

Introspective: Moist Robots

I liked this book so much I bought it
for my brother's graduation gift!
One thing you need to know about me is that I'm a huge fan of Mr. Scott Adams of Dilbert fame. Sure his Dilbert comics are funny, but I'm much more fascinated by his non-Dilbert writing. I'm over halfway through his latest book, How to Fail at Almost Everything and Still Win Big, and it's a fascinating read. One concept that he's hit on multiple times, both in his book and in past blog posts, is the concept that humans are much more like moist robots than logical, rational beings. What we believe to be free will doesn't actually exist; all choices are determined by a combination of previous experiences, our body's current chemical makeup, environmental conditions, etc.

While I don't fully agree with Mr. Adams on the matter of free will, his hypothesis has tuned me into things that are easy to control and also lead to good decision making (versus leaving choices as hard and having to exert willpower, which is unsustainable). I was able to flesh these thoughts out a little more when a co-worker of mine asked me to revise one of our proposals to Agile2014 in response to the reviews we were getting. Our proposal, entitled "The Secret Sauce of Agile" (I'm open to alternative titles, by the way), builds on Mr. Adam's hypothesis that we are moist robots. I'd love your feedback on it.

Now let's switch gears and talk about how hard it is for lifelong fat people (such as myself) to lose weight. This is another topic that Mr. Adams covers in his book (though I haven't gotten to that part yet). I've had periods of relative health, but it's only considered health relative to the rest of my life. Compared to people who are actually healthy people, I don't think I can say I've ever been healthy. So I've been trying to get healthy by using the concept that we are moist robots. I have been on the lookout for things around me that are easy for me to control which will, in turn, make it easier to make healthy choices.

A lot of the things I am doing are just good sense: don't buy unhealthy food at the grocery store; don't go shopping when I'm hungry; don't carry change and small bills for vending machines; pack my breakfast and lunch; carry a water bottle; keep gym clothes in my vehicle; etc. The idea is to not focus on changing the hard things. I'm not going on a grapefruit juice diet. It's just not going to happen. But I can change a bunch of little things quite easily so that, when the time comes to choose between healthy and unhealthy, I can pick healthy choices while expending the least amount of willpower. After all, we humans have limited willpower to expend daily (some more than others).

This is applicable to everyone and everything. Use this with your Agile teams. What problems are the team having? What small, simple things can be done to prevent those problems from surfacing? What tweaks in the way your team runs can be applied to make it easier for each person to make more Agile choices? Seriously, what? Bring this concept to the table and let me know how it goes!

Tuesday, January 14, 2014

Addendum: Agile 2014 Proposals

I blogged recently about a proposal I submitted to Agile2014. As the deadline for submission is today, I won't be asking for your feedback on the submission website (unless you're a reviewer for the track). However, I'd still love to hear your thoughts here on the blog!

Additionally, I have assisted a co-worker with putting together 3 additional proposals as co-presenter. I'd like to share the information on all of these proposals here with you now. I cannot over-emphasize how much I want to hear what you think about them!


Practical Application of Dude's Law: Come Play the Value Estimation Game!

Abstract:

You know how you determine the "bigness" of your work and establishing commitments, but how do your customers ensure you're committing to the right thing?
Come experience relative estimation to determine value. We'll use David Hussman's "Dude's Law" (Value = Why? / How?) to prioritize the work.
We will share techniques for determining the "Why?" so that you can generate a Value Index. What many people will be surprised to learn is that they already have tools for sizing that can be used for determining value and prioritization.

Information for Review Team:

The break-out of the 75 minutes would include:
3 minutes: Introduction to Dude's Law and the Value-Driven Heuristic
10 minutes: Explain and model the first exercise (Team Estimation Game for relative sizing)
10 minutes: Have round-table teams execute first exercise with a set of 10 features
5 minutes: Explain and model the second exercise (Team Estimation Game for relative benefit - same mechanism, so it takes less time to explain and model)
10 minutes: Have the round-table teams execute second exercise with the same set of 10 features
10 minutes: Have each team determine the Value Index of each card by applying Dude's Law
15 minutes: Have teams share their outcomes, insights
12 minutes: Explain the flexibility of Dude's Law (you can use Planning Poker or whatever technique works best for you) and introduce them to concepts such as Weighted Shortest Job First and Value Dial weighting*

* As this section is the least important it may be reduced or eliminated if previous sections run long

Prerequisite Knowledge:

The concept of Relative Sizing (Story Points, T-shirt sizing, etc.)

Learning Outcomes:

1.       Experience and learn how to apply a practical, proven game for prioritizing your work based on value
2.       Understand that using a heuristic for valuation is better than both gut-feel and over-engineering
3.       Understand that, as with estimating size/cost, the real value comes from the conversation

Presentation History:

I've done the Team Estimation Game dozens of times before with as many teams and have done the exercise including benefit to determine a Value Index with at least one of those teams. I also have led Program Management teams through a very similar prioritization matrix model that leverages the concept of Weighted Shortest Job First.

Comment:

My presentation is a reflection of my own beliefs and experiences. None of the material I present should be interpreted as an endorsement by my employer. I have received express written permission from David Hussman to reference Dude's Law, and I am a Certified SAFe Program Consultant (SPC), which qualifies me to speak on their Weighted Shortest Job First (WSJF) Framework.


The Secret Sauce of Agile

Abstract:

Humans are basically moist robots. As much as we like to think that we are logical, rational beings, we really aren't. The best thing we can do to improve our decision-making is to influence our environment and develop skills that will increase the odds of making the right decisions.
Beyond the techniques, practices, principles, and even beyond the manifesto; that's the secret to Agile success. Through dialog, games, and an open agenda, we'll explore that secret. Together we'll find the next evolution of Agile via application of that secret.
The foundations of Agile are human centered and scientifically backed. To get the most out of Agile and to leapfrog beyond it, we need to understand how Agile works. It's the wiring of our social minds, the relationships, tacit knowledge, and our predictably irrational natures that ensure Agile success and doom all other approaches. So, what is that secret sauce that mix of ingredients?

Information for Review Team:

Introduction (7 minutes)

We will discuss the hypothesis that influencing those factors that determine our decisions is a more effective use of time than simply exerting willpower to make correct decisions. We will introduce factors of significance that we have already found and invite the audience to provide others.

Mind Mapping (50 minutes; up to 10 minutes per factor)

We will use mind-mapping to explore what we can do, as practitioners and coaches, to increase our odds of success by influencing:
1.       Knowledge and skill-set (what knowledge, if internalized and applied, will help us make the right choices?)
2.       Environment (How can we modify our physical environment to make us more successful?)
3.       Chemical makeup of our bodies (What foods, drinks, and activities make us more likely to succeed?)
4.       Removal of guesswork (What decisions can we make when in a "rational" state that will lessen the impact of impulse decisions when we're "irrational", i.e. conflict protocols, etc.?)
5.       Others as identified by the audience

So What? (Remaining Time)

Use the information to help those in the audience generate actions based on their new knowledge to help their teams and organizations succeed. This is not a theoretical exercise; this is an Inspect & Adapt exercise rooted in human psychology.
We are prepared to adjust the presentation style depending on the seating arrangement; we can make both work well.

Prerequisite Knowledge:

Deep experience with breathing

Learning Outcomes:

1.       Learn the success secrets of Agile embedded in human behavior, social science, and the way we're wired.
2.       Learn to use science and human nature to go beyond Agile.
3.       Walk out being able to use your knowledge to be more successful with Agile.
4.       Move to the next evolution of Agile.

Presentation History:


This is a new approach that we're experimenting with currently with small teams and leadership groups. The agenda is loose because every group is different and responds differently; our goal is to let those present take ownership of the meeting and take it where they need it to go.


Flexible IT Using Enterprise Kanban

Abstract:

We will walk through multiple examples of how to setup visual signaling systems to replace the wasteful reports, meetings, management, tools currently used to track, prioritize, manage, and control portfolios, investments, programs, and projects. This talk will describe the essentials of how IT can adapt to massive disruptions. The story comes from one of the world’s largest companies. We've altered things to form a generic story; but the techniques are proven, simple, working and effective. These disruptions are constant major shifts in technology and business that have been canceling and starting new programs / projects for years.
Big data, competitive innovation, mobility, leverage, and fluxes in profit and loss have had huge impact over IT. Consider having to building a data center, starting a big data pillar with hundreds of specialists, and dropping large portions of budget all at the same time. These disruptions cannot be planned for their adaptations in response to technology, financials, and business changes.
To protect the innocent, this story details in this discussion have been formed in the form of a story. However, this leverages stories from a successful implementation of enterprise kanban at a major retailer. The approach is so simple it may not seem realistic. But stories of dealing flexibly with disruption are becoming common. Our stories will be richer and will have more real without any complexity. This story leverages a chain of values, decentralized and centralized decision-making, transparency, collaborations, evolutionary architecture, and innovations. These form the backbone for allowing a simple kanban system manage the flow of a flexible approach to dealing with global, enterprise disruption.

Information for Review Team:

Ideally, this would use large post-its and sticky notes with strings in a live demonstration. Our current system uses LeanKit; but we'd like to present tool agnostic.
The break-out of the 75 minutes would include:
5 minutes: Introductions - A story of 5 Continuous Crucial Conversations
5 minutes: Pre-requisites to Flexibility
5 minutes: Disruption – Innovation – Zero Click Shopping
5 minutes: A Flexible Response –Enterprise kanban in Action
5 minutes: Business Leadership - Reprioritize IT funding (Business Investments)
5 minutes: IT Leadership – Adjust IT capacity and create big requirements– (epics)
5 minutes: Domain Leadership - Breaks big requirements into pieces, rank, and distribute work (sub-epics)
5 minutes: Team of Teams Leadership - Form domain teams, Break sub-epics, and rank (features)
5 minutes: Teams - Break features into stories, Deliver solution parts (stories)
5 minutes: Enterprise kanban as an Innovation engine
5 minutes: Enterprise kanban supported by Lean IT & Kanban Services
5 minutes: Enterprise kanban as an Execution engine
15 minutes: Q&A

Prerequisite Knowledge:

Have to have worked in mindless, massive, and. Mismanaged companies. Need to have intimate, firsthand knowledge of corporate waste, stupid status and other mindless bureaucracy. Must have years of experience trying to do the right thing while working with overly complex, boring and unproductive program and portfolio management policies, processes, methods, tools and people.

Learning Outcomes:

1.       Walk out being able to setup a simple, flexible way to connect the effort of teams of teams.
2.       Trace funding, strategy and progress to value delivery.
3.       Increase visibility and communication while decreasing reporting, meetings, and planning.
4.       Know how to use enterprise Kanban to replace status reports, time sheets, and management.
5.       Having talking points and examples that will help you set your organization free of vanity metrics, over processing, and micro management.

Presentation History:

Not formally presented outside the company internal Agile User Group


Leading Agile Transformation from a Beach: 2 Agile Coaches’ Journeys

Abstract:

Todd and Mike have both experienced the growing pains that come from becoming Agile and helping others with the same. They had similar experiences and learned similar lessons, but their journeys have been surprisingly different. One took 15 years, the other took 5, and both took longer than they had to.
This is a story of what not to do, what to do, and how do it by not doing anything. It pulls from at least six multi-year Agile transformations in some of the world’s largest companies. We'll share our experience in a story that is sometimes funny, mostly true, and utterly real. We'll save you from failures, help you see new ways of transforming yourself, teams, companies, and cultures. Or, perhaps, we'll just provide a self-affirmation opportunity for you to confirm that what you are doing is much more intelligent than what other Agilists have done.

Information for Review Team:

May have to protect names to save the innocent and spend less on legal fees. Combined transformation experience of almost 2 decades covering thousands in major companies and consulting firms.

Prerequisite Knowledge:

Must have lead an Agile transformation of a team, set of teams, company or, that hardest of all Agile transformations - yourself.

Learning Outcomes:

1.       Build confidence
2.       Teach you how to transform without working
3.       Help you avoid stupid transformations

Presentation History:

First time for this one. Parts shared at PMI chapter and local Agile User groups.

Attachments:

Friday, January 10, 2014

Agile2014 Proposal

I really want to present at Agile2014, and I think I've got a decent proposal. But I'm biased, so I'm asking for help. Please check out my proposal at https://submissions.agilealliance.org/sessions/1691 and leave a comment/review letting me know what you think. Submission deadline is coming up soon, and I appreciate any and all feedback!

Unexpected Consequences of Agile: The Business Cares about People

In the late spring, early summer of 2012, I became the Scrum Master for a team that had already been Scrumming for about 2-3 months. They had a business customer from an area that did not have an historically good relationship with IT, and she was fully dedicated to the team. Over the next several months I helped the team overcome some of the largest obstacles that first-time teams typically face; as a result, the team got much closer to each other than they ever would have expected.

Then the time came to start another team. A couple of the members of the team were technically "on loan" and knew from the beginning that they'd eventually move off to this new team when the time came. So the "Resource" Managers let the Project Manager and developers know; the Project Manager let me know and went to the "appropriate" "Resource" Manager for the existing Scrum team to back-fill the developers. This was nothing new to them - it's how we always worked. The only real difference was that all of the developers who were being put on Scrum teams were only allocated to that one team, a concept that was totally new to our "Resource" Managers. All in all, we were pretty proud of ourselves.

What we didn't count on was the relationship that our Business Owner had developed with the development team. It used to be the business would hand the work off and we would do whatever we felt was necessary to get the work done. Moving people on and off of projects was status quo. Business Owners didn't know and didn't care who was working on their request.

About a Sprint before the change was to take place, we went disc golfing as a Scrum team building. We split into 2 groups (limited WIP) to keep from holding up traffic, and I ended up on the team with the Business Owner -- but NOT the PM. About 75% into the team building, I rather unfortunately made a passing remark that alluded to the two developers leaving the team soon. I was pressed for an explanation which, when given, completely deflated the mood of the activity. As if I wasn't bad enough at disc golf, I now had to throw through the now palpable tension.

The fallout of that experience taught us all that we can't ask for our business owners to get more involved and still treat them as if they weren't. I'm grateful that the failure was not only fast but relatively small, giving us a lesson that benefited us greatly later on when we had more teams and the stakes were higher. We're still learning about the new dynamic between IT and their business counterparts, but this one was particularly meaningful and memorable.

What lessons have you learned as Agile has reshaped your team dynamics? What cautionary tale would you share? I'd love to hear!

Wednesday, January 8, 2014

First (Legit) Introspective: Social Time vs. Quiet Time

Time Vortex, or Arctic Vortex?
The first couple of days this week were surprisingly productive for me. I say surprisingly for two reasons: 1) the "Arctic Vortex" (which totally sounds like something out of Doctor Who) caused school cancellations, along with reduced attendance at work and cancelled meetings; and 2) I still ended up spending almost all day Tuesday in meetings. This means that I was improvising on Monday and having my day planned out for me on Tuesday, neither of which have very good track history for me.

A couple of things made these days productive. First, my team spent some time on Friday to populate our backlog, which was in serious need of grooming. Having work ready for me to pull made it so much easier to fill my time productively. Please note that I'm not saying I'm not productive without a well-groomed backlog of work to do, just not as productive. Second, I had a nice balance between time to work with people, socialize ideas, and have healthy debate, and time to sit quietly at my desk and knock out work that needed to be done.

SERENITY NOW!!!
I've spent the better part of the year encouraging people to work together more: increased collaboration, co-location, pair programming, and the like. So the thought that I needed time to myself to be productive never crossed my mind. It was a weird realization to have, to say the least. I'm glad I had this experience (and even more glad that I took the time to reflect on it) so that I can more easily relate with those who raise concerns about the lack of personal space and private time as their team transitions to Agile. I also need to brainstorm ideas for creating a quiet, private space in the midst of a chaotic, Agile team environment. Any suggestions?

Tuesday, January 7, 2014

Group Affirmations - Good or Bad?

Have you ever been in a meeting where everyone is talking the whole time but nothing gets accomplished? Of course you have. Have any of those meetings consisted of everyone agreeing with everything? Maybe, maybe not. I have. Lately, I have a lot. Let me explain.

I've been in meetings with other Agile supporters discussing what it is we want to accomplish within the company and how we're going to do it. All too often, these discussions turn into someone saying something and everyone else agreeing and elaborating on it - similar to the Improv principle of "Yes, and...".

I have mixed feelings on these meetings. When I first left one of these meetings, I left feeling pumped up and enthusiastic about the work that was ahead of me. However, after several more of these meetings, I began to leave feeling frustrated and annoyed. We were talking a lot but saying nothing. We weren't generating action items or progressing the cause in any way.

I've titled these types of meetings "Group Affirmations", and I think I've come to the conclusion that they can be useful in moderation to help inspire and uplift a group of people who need a morale boost. However, Group Affirmations do not produce any real results and can have detrimental effect when over-used. I'm still forming a conclusion, though, and would love to hear your thoughts.

Friday, January 3, 2014

Introspective addendum

As I started today's Introspective I realized something important: Fridays won't work for Introspectives. For starters, I've only had a few days to reflect on this year. Also, I'm much more likely to be off work and/or unfocused on Fridays.

So I'm failing fast and moving my Introspectives to Wednesdays. Now I just need a volunteer to come to my desk each Wednesday and say, "Mike Mike Mike Mike Mike! What day is it?"

Thursday, January 2, 2014

New Year's Resolution: Kaizen!

If old acquaintance be forgot and never thought upon then you're not holding retrospectives correctly.
I've never been a fan of making New Year's Resolutions - their short life spans are clichéd for a reason. I've also been reading Scott Adam's new book "How to Fail at Almost Everything and Still Win Big", and one of the major themes in the book is that goals are for losers; winners use systems. This resonates with the Agile principle of continuous improvement through inspecting and adapting.

So my New Year's Resolution this year is not a goal, but truly a resolution. I resolve to exercise personal Kaizen. Continuous improvement has been a major part of my life for as long as I can remember, but it hasn't always carried the urgency associated with Kaizen. I'm going to experiment more so that I can fail more so that I can learn more. I'm going to schedule Introspectives (1-person Retrospectives) on a regular basis whereby I can challenge my own personal status quo.

I wouldn't be an Agile Coach if I didn't encourage each of you to adopt Kaizen as a New Year's resolution as well. If you don't like the commitment associated with that term, can you commit to trying it just for January? Each Friday in January, I challenge you to hold your own Introspective. Ask yourself what you did well and what you could have done better. You may have made good decisions, but did you make the best ones? Did you have an answer for each time you were asked "Why"?

I'll be sharing the results of my own Introspectives every Friday this year. What I share may not be comprehensive, seeing as how I don't have the time to write out all the context for my results, but I'll share as much as I can within reason. I'll also work hard to blog frequently between Introspectives in an attempt to get more of a dialogue going than I've been able to in the past.

If you decide to take on my challenge, please share your results with me. You can comment on my blog, message me on LinkedIn, or tweet me @MLCarey321. I'd love to see the effects of personal Kaizen in your life!