Written by Rick Austin Wednesday, 5 March 2014 08:55
The goal of software delivery teams is to deliver value, at least successful software development teams do this. Often, the term flow is used to illustrate the ability of a team to quickly deliver value. By way of an example, I want to provide a few patterns that interrupt flow – patterns that are common in most of the organizations we work with.
In many organizations achieving flow is much easier to interrupt than it is to establish. So what are the specific organizational challenges we face when we encounter impediments to flow and how can we create flow?
First an analogy. Bernoulli’s principle and equations in fluid dynamics are found in a variety of situations when liquid and gas are present. These principles are the reason why an aircraft is able to fly. Aircraft wings operate from air flowing over the top of the wing’s surface which is longer than the bottom surface of the wing. This faster air flowing on top of the wing generates a pressure differential that creates lift and propels airplanes into flight.
When impediments to flow are present we can reduce or even eliminate lift, leaving the wing unable to perform and obstructing flow through the system. Another interruption that can occur from the obstruction of flow is we begin operating too steeply. This leads to a situation called stall, which we can directly tie to what we see in many of today’s organizations. These interruptions to flow change the wing and contribute to it not performing well. In the case of a stall, recovery may be possible at great cost or not possible at all. Lets discuss some real challenges to flow in many organizations.
Impediments to Flow: Team Structure
A common problem we see is around team structure. A fundamental principle of agile is to create stable cross-functional teams. This creates the correct shape for the wing that improves flow. The familiar forming / storming / norming / performing loop that all teams experience represent an improving wing design as they transition from forming to performing. Unfortunately, teams are often not formed to stay together. You know the pattern, form a project team and just at the moment in time that the team, or the wing, is performing well they are broken apart and new teams are formed for the next project. This creates churn, interrupts flow, and undermines the performance of the team. Once we have a wing that is performing well, leave well enough alone and bring the appropriate work to the team. This brings up a deeper topic around the importance of forming teams correctly which has been discussed by Mike, in Failure Modes of Team Based Scrum.
Impediments to Flow: Lack of Co-Location
Challenges arise when organizations are unable or unwilling to increase co-location of team members. I’ve seen patterns where an organization will split teams up just to get some cross-architecture or cross product discussions started. In one situation, component or product area teams were split so each team had one person from each area and created a situation where there was very little co-location. Though there are certainly collaboration techniques that can help, I compare this to the challenges you have when frost or ice appears on a wing. It will work but at reduced efficiency and higher costs (why are we burning so much fuel?). This may be unavoidable but just as airlines must invest in de-icing capabilities a lack of co-location will require an investment in better collaboration tooling and more rigor in software development processes.
Impediments to Flow: Non-Sustainable Operations
Wings are designed to function within a set of operational tolerances. If the aircraft operates outside of those tolerances then the integrity of the wing diminishes to the point of failure if the situation is not dealt with accordingly. Similarly, our teams have a natural cadence of delivery that is sustainable for the long haul. If they are required to operate outside of that cadence, they exceed the team’s tolerances for delivering quality work, then the integrity of what the team delivers diminishes. This may result in low quality, team member burn-out, and an inability to deliver.
Impediments to Flow: Lack of Direction
Smooth air creates an opportunity for a wing to perform at its best. If the wing is asked to perform in great turbulence then it will operate with less efficiency and could stall. Similarly, teams need to have a clear understanding of the problems they are trying to solve which creates alignment across team members and across other teams. A lack of alignment is similar to operating with great turbulence, the teams churn, have a lot of rework, reduced quality, and unsatisfied customers.
I worked with an organization once that had been working on a project for two months. When the company brought stakeholders into the room to articulate what the problem is they’re trying to solve, it took over two hours to achieve a shared understanding on what they’re trying to accomplish. I expect the teams that had been working for the past two months had created value but I suspect it was a bumpy ride with some frightening moments. A clear direction would have created better alignment and allowed the team to operate more efficiently, better flow.
Creating a Well Formed Wing
Improving flow will allow our teams to perform better, create more lift. Doing so is not something that happens by chance. Some things to think about to help your teams fly include:
1) Create the correct team structures, structures that allow the teams to stay together and operate well so that we can increase flow. And when we do increase flow it should be because the team understands the strengths and weaknesses of each other and they have a sense of performing together. Collectively they’re not the individual parts of the wing but instead they are actually performing together as wings in flight. Create smooth air and reduce churn so the teams can focus on delivering value.
2) Attempt to create co-located teams where possible. When unable to do so then make investments in de-icing such as better collaboration tools, increased use of video conferencing, and though more costly, increased rigor in your processes.
3) Don’t ask the team to operate outside of their tolerances for delivering well-working, high-quality code. Don’t break the wing. Understand what those operational tolerances are and respect them. Teams need to operate in a sustainable manner, at a pace they can continue to operate for the long haul. Don’t let them stall. Instead let’s have them perform well and deliver, as we need them to.
4) Let’s also create flow through alignment. We should be talking more about how we can create a solid vision and understanding of the problems we are trying to solve. We should be talking more about how we can frame the problem in order to obtain a clear understanding of what we are trying to accomplish. Let’s focus on providing the sufficient requirements and make sure the organization, in particular the product owner organization, is collaborating closely with the team, providing the team with the tools and the information they need to clearly solve the problems of their customers. Don’t push the team to work in turbulent air, which decreases their ability to perform and could cause them to stall.
I would love to get your thoughts on whether or not this analogy is useful. It made sense to me when it popped into my head but then again I have more things in my head that don’t make sense
Here’s to creating wings that have great lift and operate safely.Be The First to Leave A Comment
Written by Steve Povilaitis Tuesday, 4 March 2014 08:17
Many organizations have trouble communicating effectively between executives, product owners, and developers.
Because they are trying to decompose high-level epics into granular user stories.
Features are needed to scale, because it’s too difficult to manage large programs with just user stories.
What’s the best way to use Agile features to manage large enterprise programs?
I recently worked with a large mobile telecom where the organization had been breaking epics directly into user stories. They were experiencing issues and didn’t find it effective to go from big, high-level epics to small detailed stories. This is a challenge I see at a lot of organizations and there is a simple solution, features.
Features are needed to scale, because it’s difficult to manage large programs with just user stories. Release planning becomes too detailed if you don’t have a middle tier of features representing what you’re trying to build. Without features you lose the ability to coordinate across teams effectively and are not able to provide enough context about the higher level value and goals. You need features to define the product, coordinate, and plan what you’re going to build at the delivery team level.
It is much more effective to discuss what the development teams will deliver in the future by describing it in high-level features, particularly for folks at the senior leadership level, senior product owners, and executives. User stories do not resonate with them, because they’re too granular. A senior executive doesn’t want a list of two-hundred user stories that you’re going to deliver in the next release. They don’t have time for all that detail. They want to talk higher level about what key capabilities are going to be delivered in this release, six months or a year down the road.
You apply a lot of the same rules for features that you do for user stories. You deliver features frequently, synchronize your work across teams, and limit your work in progress for features just like you would for user stories.
Tips for Agile Features
There are a few rules that I try to impart when I’m dealing with features. I like to allow features to span iterations, but I generally don’t want features to span releases. By that I mean, if you have a product release six months down the road, you want to make sure that you’ve got all the features you’re going to build within that release and you don’t have a feature that’s partially in one release and partially in another release.
It’s important that your organization doesn’t feel like the product roadmap and features are etched in stone. The features may change based on new challenges that the team has discovered. You may discover that one particular feature is going to take longer than you expected, and so it’s important to review this feature set in a regular cadence with senior leadership, so they know what to expect in the future. Don’t set the false assumption with senior executives that the feature set is fixed and it’s not going to change. This is software, and things always change. Contrary to popular opinion I find executives are pretty amenable to change. They just don’t like surprises.
When you define features, they need to be associated with a particular goal of the system. If the feature does not align to a particular goal you may start having feature creep and orphan features. Your product owner team should be responsible for making sure each feature is aligned with a specific goal. The product owner team should take the big picture that’s being discussed at the portfolio level and decompose those long-term objectives into release-level features. It’s also their responsibility to take those features and help decompose those into user stories. I recommend you do that by defining the product roadmap and conducting roadmap workshops or release planning workshops.
Another important responsibility of your product owner team or core product team is to make sure that dependencies between features are managed. The best way to do that is to make sure there are as little dependencies as possible and to make sure that features are as self-contained as they can be. Ensure features are not dependent on aspects of other features.
Just like user stories, features can be described in what we call the traditional “Three C” format, card, confirmation and conversation. The three C’s help your team gain a shared understanding of the feature. You can confirm your shared understanding of features with acceptance criteria and visual specification. The visual specification can be a use case diagram, sequence diagram, wire-frame diagram or mock user interface. Just provide a visual representation to describe what product capability the feature provides.
I hope I’ve inspired you to look into whether features would help your organization. If you are using features, I hope you’ve found some value in revisiting the best way to utilize them. If you are not using features, take some time to investigate if there are communication break downs when product owners are breaking their epics into user stories.
What are some tips you have for using user stories?Leave Your Comments. There Are Currently 2 Comments
Written by Mike Cottmeyer Monday, 3 March 2014 09:17
I don’t consider myself an expert on designing compensation systems, but as of late this issue has come up with several clients, and of course, I have to deal with compensation issues leading LeadingAgile. I’d like to share some thoughts with you guys, get some feedback, and maybe even generate a little healthy debate.
The key challenges around compensation, at least for me, center around figuring out how to reward individual performance without encouraging internal competition, local optimization, or one person feeling rewarded while another feels punished. You want compensation to motivate people, not to have a negative impact on performance.
Ever since I read Dan Pink’s Drive I’ve been very aware of the distinction between intrinsic and extrinsic motivation. While you’d like everyone intrinsically motivated… the realities of having a mortgage, consumer debt, household expenses, kids that need to go to college, or even saving for retirement drive different extrinsic needs.
Some folks want to come to work, do a great job, and go home. Some folks want to go the extra mile and really make a difference. Some poeople really want to kill it, advance their career, and be rewarded for all that hard work. Just saying that everyone should get a fair base salary, with no performance based component, isn’t going to work for some people.
So the question becomes, is it possible to use money or other rewards to recognize performance without introducing the negative side effects? Can we build a compensation system that values collaboration without creating internal competition, local optimizations, or risks leaving one person feeling punished because they didn’t get as much as their peer?
Here is what we are doing with LeadingAgile…
First, we have all our coaches is a pretty narrow salary range and we are working to narrow that range even further. When we started hiring a few years ago, I was pretty risk adverse and you really had to be a true believer to come work for me. As we grew, salaries increased and we are making things right for the people that joined us early.
As a quick aside, I want to be able to justify numbers if we ever decided to publish salaries internally. For the record, I am totally open to full transparency and think it’s a good idea. Some folks aren’t so keen on the idea, so we are respecting that for now. It does influence decision making around salaries when everything might be out in the open some day.
We believe that baseline performance is binary, you are good enough to be on the team or you aren’t. We are starting to get more explicit about what it means to be good enough to be on the team, but if we hire someone, we have very high confidence they can work in our model and be successful. Occasionally something will come up after the fact, but that has been rare.
If you are good enough to be on the team, you share in the team’s success. For us, that means a 20% bonus on top of your salary. Everyone will get the bonus or no one will get the bonus. We are toying with quarterly payouts but for now, it’s annual. The idea is that if the company is successful, we want to share that success with everyone.
Success for the time being is defined as 75% utilization. We’ve debated setting the target a little lower and we’ve discussed a sliding scale. There is a ton the utilization implies about our ability to market, sell, deliver services, and manage cash… so it’s not just about revenue. That said, revenue is what drives our ability to get people paid.
Does this fall into the category of an extrinsic motivator that might actually demotivate people? Maybe. But how else would you share financial success when things are going well? If we just added that 20% to each salary, my cost structure would be too high should we underperform financially. I’d have to let people go in a slump and that’s not the goal!
We are intentionally falling on the side of keeping our cost structure in check and rewarding the team if we are able to perform at a high level. We are building the infrastructure to help the team support marketing and sales, educating folks on how to manage engagements, and really encouraging people to pay attention when we have unexpected downtime.
I’m hoping that by taking a whole team approach, keeping everything visible, and empowering everyone to influence the goal we’ve been able to strike the right balance. Time will tell.
That said, we still haven’t addressed how to compensate the people that really want to kill it. Those consultants that want to hep market and sell, grow the practice, lead multiple accounts, and create sustainable economic value for the company. If someone is able to create that kind of value, I need to reward them or they’ll leave our company and start their own.
We are looking at introducing a variable component to our salary structure based on several other metrics we think might be relevant: overall financial contribution based on sales and marketing activity, the ability to keep yourself busy on one or more accounts, willingness to grow and develop professionally, customer feedback and peer feedback.
The idea is that for an individual component to pay, the team would have had to meet its overall goals. No local optimizations. Any compensation model over and above base salary and team based goals would have to meet certain design criteria to make sure it adequately rewards individual performance but doesn’t feel punitive to those that don’t make it.
It has to be inclusive… anything that one person is able to do, everyone is able to do. There can’t be some named subset of people able to participate in the plan.
It has to be based on abundance … everyone is able to be at the top every time. We want to build a system that assumes everyone has the ability to be a top performer.
It has to be transparent… whatever we choose to measure will be tracked openly so you can see where you are relative to your peers at all times. The measures and goals have to be clear and attainable.
It has to be cooperative… there cannot be any penalty for working together to achieve a goal. If two people work on a goal together, the reward has to be as much or greater than working on it individually.
It has to be sustainable… we will only ever reward sustainable growth. Creating incentives that encourage people to only look out for short term economic outcomes won’t help the company grow.
My hypothesis is that if we can fairly compensate people by way of base salary, give everyone something extra if we hit our financial targets, and create an inclusive, abundant, transparent, cooperative, and sustainable model for paying one person more than another… we might have a shot of making it work and allowing folks to meet their individual financial goals.
If an employee receives a fair salary, is compensated when the company does well, but decides not to participate in the broader plan… they may not like that they didn’t get anything extra, but at least they’d understand why and know what needed to happen in order to participate in the future. If your good enough to be on the team, that door is always open.
Okay… so what do you think? Is it fair or a slippery slope? What could we do differently? I realize we are a services company, but could these ideas work in a traditional software company? Would a model like this work for an agile team? An agile enterprise? If it would work, what kinds of measures might we consider for software developers and other team members?Leave Your Comments. There Are Currently 9 Comments
Written by Mike Cottmeyer Wednesday, 26 February 2014 10:13
Okay… let’s set a little context here. In my last post we talked about two different types of projects. The ones that are knowable and the ones that aren’t knowable. Projects where it makes sense to estimate and projects that are more like R&D investments where we are spending money to learn and discover. Today, I want to talk more about the first kind. The ones where we do have some idea of what we are building and the technical challenges that might be involved.
Getting clarity on what we are going to build and how we are going to build it isn’t easy. This is especially true when we have multiple competing stakeholders, no clear way to resolve priority conflicts, more to do than we can possibly get done, and the technology while understandable, certainly isn’t trivial. In the face of this kind of ambiguity, I think that many of us have thrown up our hands and concluded that software isn’t estimateable and everything should be treated like R&D.
I think this is a mistake. If we keep pushing to treat everything like R&D, without understanding the delivery context we’re working within, the whole agile movement risks loosing credibility with our executives. If you remember from our earlier conversations, most companies have predictive-convergent business models. We may want them to be adaptive-emergent, but they aren’t there yet. We’ll can talk about how to move these folks, but for now we have to figure out how to commit.
Back in the day when I was just learning about agile, and immersed in the early thinking of Kent Beck, Alistair Cockburn, Mary Poppendieck, and Ken Schwaber… I came across this idea that the team had to commit to a goal or an increment of the product at the end of the iteration. There were some preconditions of course, the story had to be clear and understandable, we needed to have access to an onsite customer, and the team had to have everything it needed to deliver.
If the story wasn’t clear and understandable, there was this idea of a spike. I’ve always understood a spike to be some snippet of product we’d build to go learn something about what we wanted to do or how we were going to do it. This idea has expanded some over the past few years to include any work we bring into the sprint to do discovery or learn something we didn’t know before. It’s basically an investment the product owner makes to get clarity into the backlog.
Like most of you guys I’m sure, my planning approach was heavily influenced by Mike Cohn’s Agile Estimating and Planning book. Mike turned me on to Bill Wake’s INVEST model and I’ve used that as a tool for understanding and teaching good user stories ever since. The longer I use the INVEST model the more profound I think it is, but as widely accepted as this idea seems to be, I think there are a few under-appreciated letters in the model. The one most relevant to this discussion is the ‘E’.
E is for Estimateable
The idea behind INVEST is that these six attributes of a user story set the preconditions the Product Owner must meet before the story can be brought to the team. If they are not INVEST ready, they get deferred and we schedule a spike. The idea behind the ‘E’ specifically is that the user story must be well enough understood by the team that they know how to build it. The team has to be able to break down the user story enough to put detailed estimates on the tasks and be willing to commit.
Remember when I said that almost every disfunction on an agile team tracks back to the backlog? We’ll here is the problem… most teams are accepting user stories into sprints that are not INVEST ready and are certainly not estimateable. If the team doesn’t have enough information to make a commitment they shouldn’t make a commitment. So… do we conclude from this that software isn’t estimateable or do we conclude that we collectively do a poor job backlog grooming.
Because most of us work in dysfunctional organizations that don’t manage a roadmap, don’t stick to their vision, thrash around at the executive level, and generally can’t make up their mind… many of us have come to the conclusion that creating a backlog is waste. Why spend all that time writing up user stories when things are going to constantly change? This is indeed a problem, but giving up on planning is not the answer. Making up your backlog as you go isn’t the answer either.
When we make up the backlog as we go, everything the team encounters is going to be new to them. Everything they do is going to require a spike. The whole notion of Sprint Planning and Release Planning is predicated on the notion that we generally know the size of the backlog, we learn the velocity of the team, and based on those two variables we can begin to predict when we’ll be able to get done. If everything requires a spike, the backlog is unstable and indeterminate.
For every user story we attempt to build, we create at least one spike, and probably two to three more user stories. Even if we have a stable velocity, the scope of the release is increasing faster than we can burn down the backlog. We never end up with stable view of what’s happening on the project. The team feels like it’s thrashing, the product owner feels like their thrashing, and the organization gets frustrated because the product isn’t getting out the door.
Dealing with Backlog Uncertainty
To solve this problem… to get better at making and meeting commitments… even at just the sprint level… we have to plan a sprint or two ahead of the increment we intend to commit. That means if we want to get better at nailing sprint commitments, we need to have backlog properly groomed BEFORE the sprint planning meeting. If there is spike work to be done, that needs to be identified and done BEFORE the sprint where the user story is going to be built.
The implication here is that the team (in any given sprint) is going to have some capacity allocated toward the work of the sprint and some capacity reserved for preparing for the upcoming sprints. This could be as simple as having a meeting or two every sprint to help the PO groom the backlog, do look ahead on the backlog, to ask questions and to give guidance. Sometimes it’s more ad-hoc and sometimes it’s more formal. Some teams track this work, some just allow it to lower velocity.
Either way, allowing some slice of capacity for preparing for the upcoming sprints is an essential element to begin stabilizing delivery, agree? If you are with me so far… I’d suggest that stabilizing a release follows the same rules we just applied for stabilizing sprints. Don’t commit to anything in a release that the team doesn’t understand or know how to build. If there is a ton of risk and uncertainty coming out of release planning, Scrum isn’t going to necessarily help us delivery reliably against the release objectives.
So how do we get this level of clarity on the release level backlog? If we apply the same concept at the release level we applied at the sprint level, we’d have to suggest that the team has to do spike work BEFORE they get to the release planning event. That means that we need to have some idea of what’s in the upcoming release, and the unknowns associated with that release, BEFORE the current release is even done. If we are doing 3 month releases, I’m looking for high-level planning somewhere between 3 to 6 months out.
That’s NOT Agile!?
And here is what I’ll inevitably get when I make this point with some folks. Hey Mike… that’s not agile!? That sounds like Waterfall. You’re suggesting that I have to plan 3 to 6 months out, at the detailed user story level, in order to stabilize delivery and make and meet commitments at the release level? Just to be clear, that is EXACTLY what I am saying. And that begs the question… what is agile? What exactly does it mean to be agile at the corporate level.
In the context of a predictive-convergent company, one that is doing projects that are not R&D, where it is reasonable to understand requirements, and the technology is not totally unknowable… yes, it is perfectly reasonable and advisable to start looking at your backlog 3 to 6 months in advance. Maybe not at the finest level of granularity, but we need enough understanding of what we are going to build, and how we are going to build it, to sufficiently groom the backlog and mitigate risk.
Corporate agility comes not from the practices of Scrum, or from making your backlog up as you go, but from creating the ability to change your mind as you learn new information. If I plan ahead, sure I may create some waste and incur some carrying cost due to a longer backlog, but because I am building complete features in short time-boxes, and working toward potentially shippable code every two weeks, I make it easier to change direction. Some level of forward planning is the cost of making and meeting commitments.
I’d go so far as to say that in a larger organization, changing your mind every two weeks is the equivalent of thrashing.
Most companies need to be able to change their mind every quarter, some only every six months. Most do not need the ability to change their mind every day. In this case, if we can stabilize the roadmap, get some basic governance, apply some Lean/Kanban based program and portfolio management, and disciplined release management… you can get a stable well groomed risk adjusted backlog. And it is possible to estimate and make and meet commitments.
We do it with our clients all the time.
Building My House With Agile?
And this is why I told you the story about building my house. I think the metaphor holds well in companies that are trying to deliver in the predictive-convergent problem space.
1. We routinely recommend a 12-18 month roadmap level plan. Initiatives are broken into 2-3 month increments that can ideally be delivered within a single release. The roadmap isn’t just about business goals, it also has architectural guidance and maybe even high level UX. It’s enough to understand what we know and what we don’t know and provide budgetary estimates that should be close enough to reality such that they establish reasonable constraints. This is analogous to the time I spent with the builder coming up with the architectural design, feature list, and budgetary estimates for my home.
2. We routinely recommend a 3-6 month feature level plan. This helps us get clarity around what we can actually build in the current release and what’s coming in the next release so we can start grooming the backlog and mitigating risk. For me, there is no hard rule for a feature level breakdown. Of course I’d like the features to be smaller than the roadmap level initiatives, but they are going to be much bigger than user stories. I like to allow them to span sprints so somewhere around 2-4 weeks seems right to me. Having this view is analogous to a construction schedule that lays out the foundations, walls, roof, landscaping etc and puts the key dates on a calendar. We still haven’t made all the fine grained decisions, but the project is starting to come into focus.
3. We routinely recommend a 3 month rolling backlog of fine grained user stories. I’m not saying that the user stories have to be 100% sprint ready, but they should be risk mitigated and pretty darn small. Definitely smaller than a sprint and confined to a single team. They should have a clear definition of done and some acceptance criteria, but as we learn, we may split them up more hopefully finding ways to leave stuff out and focus on just the minimally marketable part of the requirement. This is analogous in my house building example to picking carpet color, paint color, the exact kind of hardwood and tile, and the placement of the bushes in the front yard.
Context, Context, Context
If we are building stuff that is unknowable… sure let’s not plan or estimate or commit to anything. But let’s also be clear with our stakeholders what they are investing in. They are putting significant dollars at risk hoping to find a solution to a problem that may or may not exist. That is a perfectly valid way to spend money and allocate investment as long as we are all in agreement that is what we are doing. If the stakeholders think they’ve got a guarantee, that is a problem.
If we are building stuff that is knowable… we need to have a plan for road-mapping the product, progressively breaking things down into smaller and smaller pieces, mitigating risk, planning forward, establish velocity, collaborating to converge on desired outcomes, making tradeoffs, communicating progress and reporting status. It’s not that things will never change, and maybe even our high level planning is off, or maybe we see a risk we didn’t anticipate, but at least we have a baseline to communicate how what we learned may impact the project.
If we are building stuff that is knowable… but we don’t have the organizational structure, governance, metrics, discipline, prioritization, or whatever… and it just FEELS like the work is unknowable… putting these projects in the unknowable category diminishes our credibility. Executives know this stuff is knowable. You’d be better off calling out the stuff that is broken in the organization and working with the organization to fix it. Scrum calls these organization impediments. Remove them.
In my opinion, regardless if you are a consultant or an internal employee, people appreciate a thoughtful consideration of their particular context and a willingness to adapt your point of a view to help them solve the problems they are really trying to solve. We started this thread with the notion that many in the agile community are solving the wrong problem. Even if it’s the right problem, it’s not the one that executives are trying to solve.
There is so much goodness coming out of the agile community right now. So much forward thinking and so many new ideas. Unfortunately we also see a ton of dogmatism and a profound lack of understanding about the real problems executives are trying to solve. I think we have had, and continue to have, the opportunity as a community to make a profound impact on the way companies operate and in the lives of the people working in them.
The early adopter ship has long since sailed. We are probably on the tail end of the early majority. That leaves us with the late majority and laggards just coming to the party. Maybe that’s what’s driving some of my consternation here. Maybe it’s time we start figuring out how to talk to the folks coming late to the party. Maybe it’s time to focus on how to help these folks adopt agile. For these folks it’s less about defining the end state and more about learning how to get there.
NOTE: This series has been an interesting exploration for me. We have been evolving our transformation model over the past year or so, and writing about this stuff has given me a level of clarity and understanding I didn’t have before. I’m actually talking about stuff differently than I was even a few weeks ago. I made some connections that I hand’t made previously.
This post ended up being a good setup for going back and reevaluating some of my first few posts and putting them in a slightly different context. I think what I’ll do is recap some of the earlier stuff in the new context and then build on the house stuff, planning and risk stuff, to start talking about governance and road mapping. The next few weeks are going to be a little crazy, so wish me luck actually finding time to write. Thanks for reading.
Check out the previous post: Understanding Risk in Your Project PortfolioLeave Your Comments. There Is Currently 1 Comment
Written by Tim Wise Tuesday, 25 February 2014 08:08
A while back I was invited to the AITP Atlanta Chapter for a CIO roundtable discussion that involved questions on agile. The event was a great success and I came away with a bunch of great insights into what topics are on the minds of today’s CIO. One statement that night has really stuck with me. A wise, retired CIO told me, “Don’t sell me your solution, solve my problem.”
That statement further solidified my belief that I am not “implementing agile” (hang with me), but rather I am solving a problem or a set of problems that commonly occur in enterprise environments.
We don’t sell vials of snake oil. Here’s why that may be the perception.
Let’s consider the state of affairs for a moment. When I get the opportunity to have a discussion with a new organization, the person I am talking to needs me to solve a problem. They might not know anything about agile, scrum, kanban, or any other process. Alternatively, they may have experienced a poor implementation and have an immediate bias to any of the “agile” words (i.e. sprints, daily scrums).
If I am selling them something, I genuinely want to solve the problem, not implement agile. That allows me to be a pragmatic partner with knowledge of agile systems that can benefit my customer. It breaks down zealotry and keeps me honest.
In the end, I am directly and intentionally not talking about agile, scrum, kanban, or lean or anything else that is under the agile umbrella. I simply want to know, what is the most impactful issue that their enterprise is facing right now in their unique context. Can I solve it? No, but we (myself and the enterprise) can. It must to be a partnership though to be an effective sustained transformation.
Here’s the catch. Most, but not all, issues will fall into one of several categories.
- Time To ROI
Though categorically these problems are recurring across many business enterprises, the underlying causes can be a complex, interwoven gobbledygook of methods, procedures, and people.
That’s why it’s important to listen and offer up expertise when you understand the problems. It’s an engaged dialog that I am targeting to create a shared understanding of their problem so we can work to create a vision of our solution. I’m not there just to lend an ear. That’s why I need all this experience stuff.
Speaking of experience, I have found commonality among the solutions for each of the categories listed above.
Let’s take Predictability. In order to become predictable, most organizations will need to learn how to systematically decrease batch size, reduce WIP at the enterprise and team levels, and stabilize teams. Inherently, this will increase quality and decrease Time To ROI. To further improve those, I will need to run experiments on their unique context.
How do they begin to get predictable? That’s what they need help doing. It’s what scaling agility is really all about. Getting more value out of the system to decrease time to ROI and predictably make and meet corporate goals. Informed, predictable returns on investment.
At my core, I believe a predictable system is one that we can run experiments on and get most other problems solved. That’s my key to unlocking the shared potential of both parties.Leave Your Comments. There Is Currently 1 Comment