Like many developers, I’ve been protected from apparently difficult customers by my managers and left to get on with the important job of “writing code”. But this week I left our office and headed out to a technology park to work directly with one of our customers, and after a couple of days of understanding each others needs I’ve rarely felt so excited about “writing code”, because I know it will be valued.
XP & Scrum talk about a customer on the team but I’ve never seen it happen, well not a “real” customer. Proxies aren’t the same, particularly when they are neither dev or customer. With little understanding of either side, they’re stuck on the fence, helplessly documenting and relaying demands with seemingly unquestionable priorities to an increasingly demoralised team. It’s a world away from the customer and developers really understanding each other, so why can’t we do better than this?Fear gets in the way
The developer fears the customer. I’ve spent years assuming developers would love to talk to customers given the chance, but when it came down to it, I’m seeing fear come between us. I feared being asked to do dumb things and not knowing how to say no. I feared having to explain failure and the difficult conversations that follow. Without letting myself be vulnerable I grew conservative, inward looking and start making assumptions based on what works best for me rather than what’s really needed.
The customer fears the developer. She fears being taken for a ride by these alien geeks and looking stupid when they try to dazzle her with their technical prowess. Who can blame them, I see defensive developers making an art out of making people looking stupid rather than be open and share what they don’t know.
The manager fears relationships. It sounds like a terrible thing to say, but it looks to me like many managers want people ‘under’ them to have exclusive relationships with them rather than each other. Holding tightly to our relationships lets us stay in control, but interesting things only happen when loosen our grip and let people collaborate freely.Enlightenment
This is hard, but there is some enlightenment available to those willing to step into the unknown. When we open ourselves up to sharing and learning from each other, we can start to collaborate. Once we begin to understand and attend to each others needs we can start to create something that’s a bit special.Time to build relationships
Can I propose that when it’s not possible to have a real customer on the team, that developers spends at least a couple of days a month with a customer and users? To help build the desperately needed relationships and mutual understanding, Scrummasters and Managers can help facilitate this relationship building. I think this collaboration is perhaps the most important thing we can do if we want to build something that has real value.
I want to move beyond the classic three variable problem of the project (scope, schedule & cost) and envision a model that describe the value that a project represents while maintaining the constraint relationship that these classic triangular relationships represent. Enter the Tetrahedron - a platonic solid. The tetrahedron has four faces, each face is a triangle, it is the simplest form of a pyramid with the base in the form of a triangle.
Highsmith's Agile TriangleJim Highsmith introduce the concept of treating the PM triangle of cost, schedule, and scope as constraints in his Agile Triangle by adding a fractal triangle at the vertex of his triangle of value, quality and constraints. While other's had explained the iron triangle as having an aspect of quality on the inside that one obviously would never vary. Well then if one is not varying quality while do we talk so much about technical debt? Jim does a great job explaining that the traditional aspects are constraints and that the desire of a business is to derive out of these constraints something of significantly larger value than constraint space represents.
Discussing this with my colleague Rick Stephenson we envisioned a more physical and tactile model. A model that retained the constraints concept from Highsmith, but added the multiple aspects of value -- business, technical and customer value. We desired to represent these three types of value as separate and independent aspects that must be attended to by the project team while staying within the constraints. Yet it is the desire of the project's sponsors to raise the values as high as possible while minimizing the surface area of the constraint space. When these desires are modeled in the tetrahedron with physical objects one can start to get a gut feeling for the tradeoffs that directors and managers must make in the project. Build upon a small constraint base and the pyramid may become unstable. Imagine the table upon which you are building your model to be the platform for your application - when the platform is shaky and unstable the application needs much more base surface area to attain a sufficient height (values).
In the model of the Agile Tetrahedron I made above I cut the business value face a bit and the technical value face even lower. The idea was to show that those faces may not be completely required to deliver customer value within a given release (constraint). Yet, one can see that extending that idea to an extreme may prove dangerous with a shaky platform.
Agile Tetrahedron model: print, cut, fold, play...PDF of Agile Tetrahedron model ver 2.3 - print, cut, fold, play...
How to make the classic PM Iron triangle out of plastic drinking straws.
Beyond Scope, Schedule, and Cost: The Agile Triangle by Jim Highsmith
Join me for a webinar on March 10, 2014 at 7pm Eastern. My topic is “Overcoming 7 Common Pitfalls of Transitioning to Agile in Software Engineering.” I’m speaking as part of the Graduate Professional Studies Spring 2014 Guest Speaker Series.
Partnership & Possibilities: A Podcast on Leadership in Organizations
EPISODE 9: WORK WITH US
“When I see inequity, here is how I’m responding to it, here’s how I’m trying to shift the behavior, both in myself and in creating the conditions to shift it in others.”
Running time 28:10
What are you seeing in your organization relating to gender roles and gender equality? What type of things are you doing that are helping these more subtle gender equity and equality shifts occur?
Leave a comment on this blog or email us at email@example.com
[Intro] Conundrum faced by women in leadership roles and in the workplace.
[01:14] Review of “Work with Me” by Barbara Annis and John Gray.
[04:54] Gender issues in the workplace, but what are the solutions?
[06:09] Stereotypical male informal networks still exist in most industries.
[10:25] How men and women view gender differences and opportunities in the workplace.
[14:23] Stay-at-home dads becoming more common, but still viewed as a threat by peers.
[18:16] Becoming aware of one’s behavior gives power back to the individual.
[23:48] Women are helping change the leadership paradigm to a more collegial participative way.
WORK WITH ME: The 8 Blind Spots Between Men and Women in Business by Barbara Annis and John Gray
GENDER INTELLIGENCE: How Our Differences Create Value in the Workplace by Barbara Annis and Keith Merron
LEADERSHIP AND THE SEXES: Using Gender Science to Create Powerful Organizations by Barbara Annis and Michael Gurian
The global gender agenda: Women continue to be underrepresented at senior-management levels in Asia, Europe, and North America. McKinsey research suggests some answers.
Study: More men on the ‘daddy track’
Marked Women, Unmarked Men by Deborah Tannen
Lean In: Women, Work, and the Will to Lead by Sheryl Sandberg
Sounds silly, doesn’t it? Yet many traditional command-and-control organizations think they can work this way.
Manager types go behind closed doors and through a series of many meetings come forth with “The Plan.” The plan directs what is to be done, how it is to done, when it is to be done, and by whom it will be done. The software developers who must implement the plan are informed of the plan and directed to “Make It So.”
Almost immediately it seems a question will be raised with the realization of, “oops, that was not considered… it is not in the plan.”
But, the Project Manager’s job is to create and then deliver based on “The Plan.” They will be evaluated based on that ability. Their performance and success is measured by variances to the plan and they report these variances every month to their superiors. As is typical with human behavior, it does not take long for a savvy Project Manager to realize that, “hey, if I want to keep my job, or better yet, get a good raise or promotion, I better not have variances.” Variances to a plan are bad. So the project management function seeks to control and, thus, essentially prevent change. Change becomes a threat to success of the plan.
So, you must follow “The Plan” and stay on schedule and on budget – deliver the hours and the planned activity and events.
But, the Customer wants everything they asked for, so you must deliver all content as well. No, they cannot add anything that will change the plan.
If the developers cannot stay on task as defined, they simply must work harder and longer because “The Plan” must be good. Then they must explain in detail why they could not accomplish what they were told to do within their budgeted hours. Just Make It So.
Waterfall project management wants fixed schedule, budget, and content. Actually what they really want is that big raise for demonstrating how great their plan was and how well they controlled the project through the plan.
If this project is actually well understood up front and what’s to be accomplished is pretty stable, then this approach may actually work. Project managers are smart people too, and they can effectively apply experience and judgment to make good plans under the right conditions. Some industry is very heavily regulated and only a very precise and specific requirement is acceptable. This approach can work well and, if it does for you, then great…. Make It So.
But, what if the software product must evolve to changing conditions and needs? Today’s rapidly advancing technology means end-users are increasingly fickle about what they want. Many agile software project management products now are being provided to model business processes and interactions, either for internal or external customers. These processes are under pressure to constantly change and improve meaning that the supporting software must also change. Companies cannot maintain a competitive edge unless they change and evolve rapidly. Software projects must be prepared to do the same. Does it really make sense to tell your customer they cannot have the thing they discovered they really need now because it was not in your plan you made months ago?
Like science fiction, plans rarely mirror actual reality. Trying to fix schedule, budget, and content is a real challenge for a number of software projects in organizations today. In reality, one of these parameters must be allowed to flex. End-user software is very hard to define up front. Users often do not know what they want, and even when they think they do, they quickly evolve to need something else. Plans must be able to adapt and yet still provide the business with the insight that it needs to manage teams effectively.
This “Make It So” approach must evolve and, with it, the behaviors of project management and the measurements of project/plan success. Even really good project managers cannot control the future.
Maybe it is time to “boldly go” and explore a new “agile software development” approach – one that provides immediate visibility into the health and status of the project real-time, and readily allows for a changing parameter (content, schedule or budget) to be understood immediately.
What do you think?
What does it mean for an estimate to be right? Does that mean that later actuals had the same numerical value? That the project length, or cost, or end date was the same as the estimate? Is it an indication of the “correct length of the project,” whether or not the project is done in that time? Or is there some better definition of “correct estimate” that we can use?
If we choose conformance to actuals as the definition for the “rightness” or “goodness” of an estimate, we’re certainly encouraging overestimation. It’s easier to overestimate and then waste effort as needed to be “accurate” than to underestimate and try to hit a possibly impossible target. Those who ask for estimates using this definition know this, so they are likely to arbitrarily cut the estimate in order to put pressure on development and prevent padding. Of course, those creating the estimate notice this tactic right away, and have incentive to pad even more.
Once upon a time, I was working on a hardware development project. We were breadboarding a design for a custom Large Scale Integrated Circuit using off-the-shelf logic ICs. As we were preparing to prototype our second revision of the design, we calculated how many of what chips we would need. Then we added another ten percent for chip failures, and some more of certain chips we might need if we had to expand the design. Knowing that the boss had a tendency to cut parts orders in half, we then doubled the amount before taking it to him. Unbeknownst to us, he had just come from a meeting where our project was declared to be top priority. To better support us, instead of halving the order, he doubled it. That’s right, the order was placed for four times our best estimate plus padding for contingencies. We couldn’t, of course, admit that we had doubled our estimate. So, we said nothing. The crowning blow came when, a few weeks later, the project was cancelled before the parts were all received.
This story illustrates the sort of dysfunction we create when we play games with estimates rather than treating them as what they are. Estimates are not promises. Nor are they controls on what development teams can do. They are rough calculations that allow us to make decisions before we have all the facts. They may be gut-level seat-of-the-pants guesses based on past experiences, or they may be carefully calculated based on considerable knowledge. In either case, they are the best answer we can give based on the current knowledge and the amount of effort we wish to spend on them.
What, then, makes an estimate right?
1. It didn’t cost more than it’s worth. If we spend a lot of time and effort estimating something that won’t change any decisions, then the estimate is wrong because it’s all a waste. If we estimate an entire project by breaking it down into hundreds of small pieces and estimating all the pieces, it’s likely more work than the resulting estimate is worth. And if the result is close to the decision threshold, we’re probably working on something of too little value.
2. It errs on the appropriate side. The calculation of ICs needed for the breadboard was intended to err on the side of too many, so that we wouldn’t run short and risk delaying the project. If we’re estimating time so that we know when to start other activities that need to be delivered with our project, we might want the earliest time we have to reconsider when to start these activities. If we’re choosing how much work will fit in our next iteration, we might want to be wrong in both directions an equal amount over time so that our long-term projections are more accurate.
3. It has an appropriate level of precision. If we’re estimating what we can get done in the next year, we don’t want to be working at the level of minutes and hours. False precisions is just noise. When I was a poor college student doing my grocery shopping, I estimated to the nearest dime because I found it embarrassing to have to remove an item after it was rung up. That high level of precision was important to me. The shopping cart held only a dozen dollars or less, though, not a hundred.
4. It’s the right thing to estimate. If we estimate the amount of programming time for a project, but ignore significant interruptions for other work, we’re not going to have a good answer for the elapsed time of the project. My estimate of the cost of the grocery cart contents in my college days was the right thing to estimate, because when I reached my limit, I could make substitutions in my menu plans to fit.
These are some of the things that make an estimate right, as an estimate. You can probably think of more, and I’d love to hear your suggestions.
Getting out of the Tardis and back into “posting” here on a regular basis is going to be like getting back on a bike after a long hiatus. I may fall and skin a knee sometimes; heck, I may even break a limb… but I promise nobody is going to die on this trip.
Sit back and enjoy and engage here when possible.
In my last posting I received many many encouraging comments (thank you!) and some that caused me to pause in some of my thinking about this whole blogging thing. It seems so very 2012 and earlier (remember this blog has been around since 2006 and contains a TON of content — some crap and some jewels).
Zooming into 2014 and I am spending a lot of time out on Twitter and with my business out of Facebook because for me this is more engaging and real-time (well… face-to-face rocks but I am not able to be everywhere at once). Google+ also seems to be an interesting place.
Apparently people still read blogs (eh hem, YOU are and I sincerely want to thank you). So… I promise to answer each and every comment here (the valid non-spam ones!) and engage with you and others here. It’s another way. It seems sort of one-way to me so let’s see how it goes.
While I stated in my last post that I’ve been “dark” — it does not mean I have not been working (and enjoying it immensely). I’ll share some of the current stories and travel stories and, more importantly… I will ASK FOR YOU HELP.
Asking for help is something I TOTALLY SUCK AT DOING. I don’t think I am alone at that.
Scrum specifically helps individuals, teams, programs, portfolios and organizations show you where the dysfunctions ARE TODAY.
And. As humans, we learn to live with these dysfunctions and they become the normal noise in life.
This noise can be obvious to people looking from the outside. People like me. And. You.
Here is what I am becoming more and more aware of on a daily basis:
Instead of just treating it like noise… listen to it.
Do ONE thing to make a change.
Who needs to do this?
Ask for help to solve it.
Stop with the idea that, “I’ve got this Mike” — because I will call bullshit on you my friend (well — if we have not met yet we are still virtual friends).
In my travels lately I have been really focusing on two messages — #DELIVER and SLOW DOWN.
People. We still suck at Agile (and Scrum) at the individual and team levels.
Now the rage is scaling agile (and Scrum).
This is not a new thing kiddos (or old people here #getoffmydamnlawn).
My experience is something to learn from — scaling the RUP (Rational Unified Process) from the team level to the Enterprise with the EUP (Enterprise Unified Process) [circa 2005 and earlier].
Is that experience applicable for all situations? Of course not; however, perhaps the next post will focus on what all the new “Silver Bullet” scaling methods, frameworks, and processes look like in 2014 (and what’s coming — because there is always something coming!).
There are patterns that work well. This is “noise” we need to examine a bit more and we will do that here together.
Blogging — it’s a chance for me to share experiences.
And. I will (wahoo right?!!?).
Until the next posting, let me know how you are doing with exposing things using Scrum – and how that experience is like turning up the amplifier to eleven all the time.
Ask SOMEONE for help.
I am going to do that shortly too (because as it has been pointed out — I cannot be a “one man show” on this journey).
The early adopters of Scrum were seeking a method of controlling the chaos of emergent product development processes. They needed empirical methods to discern if the product was moving in a meaningful direction. They were willing to risk accepting technical debt to validate working solutions in the hands of real customers. They were focused on delivering value, they wanted a process that optimized on value delivery and embraced the learning process required to explore new product domains. They were organizations capable of thriving on the edge of chaos. Organizations in the early adopters phase seek to keep options open (decide at the last responsible moment), to pivot upon learning about the opening market space, to fulfill an undefined emergent need.
"Intelligence should be viewed as a physical process that tries to maximize future freedom of action and avoid constraints in its own future." -- Alex Wissner-Gross
Tardigrade - an extremophileThese organizations are perhaps a small subset of all corporations - perhaps these are extreme examples - but they exist.
But extremophiles do not live in the calm waters of the Caribbean reef.
"Most executives I’m meeting with nowadays aren’t fundamentally trying to solve the adaptability problem." -- Mike Cottmeyer - Are we Solving the right problem?
The Agile movement has reached the late majority of the diffusion of innovation curve.
The Late Majority: "Individuals in this category will adopt an innovation after the average member of the society. These individuals approach an innovation with a high degree of skepticism and after the majority of society has adopted the innovation. Late Majority are typically skeptical about an innovation, have below average social status, very little financial liquidity, in contact with others in late majority and early majority, very little opinion leadership." -- Everett Rogers
My opinion is that this group is seeking a different answer than the early adopters or early majority. Studying Rogers' diffusion curve and synthesizing some other really observant human behavioral ideas; I think it's very obvious that the late majority have a very different answer to the fundamental questions around why they are adopting Scrum. I've asked this question for years in workshops. The answer's haven't changed. But the meaning behind the answers must be different than they were before.
Is it the value system of Agile that draws these companies into the Scrum trainers classroom? No. Is it the promise of the more collaborative and humane software development lifecycle for the employees? No, many of these companies have already shed their employees by adopting the staff augmentation model of the 20th C. consultant/contractor model.
The answer this group of late majority scrum adopters are seeking is: a lowering of the cost of development and maintenance of software systems that run and maintain the business. Very few projects that these organizations attempt are in the domain of seeking an innovative or emergent solution. Sure they speak the current lingo of innovations but few are seeking disruptive innovation (what must of us think when the "I" word is mentioned), most are seeking frugal innovation (15 Types of innovation).
"Frugal Innovation is about doing more with less. Entrepreneurs and innovators in emerging markets have to devise low cost strategies to either tap or circumvent institutional complexities and resource limitations to innovate, develop and deliver products and services to low income users with little purchasing power."
This group is not seeking to open up the future options that an emergent process may afford them.
See Mike Cottmeyer's blog series What Problems Are Executives Trying To Solve With Agile? It is a very good list - if you need an answer, pick one from his list - it's sure to impress.
Start with WHY - Simon SinekPerhaps we should start our agile transition with a serious question - Why?
I've asked this question, but just getting a few mid-level managers and the executive level sponsor answering this question may not be enough. Is there a method of hearing the organization - rather than the designated spokesperson for the organization? Enter Open Space Technology. Why yes, yes I believe this may provide a collaborative way to answer the question without the filter imposed by a leadership visor. Inside of the Agile movement it may best be expressed by Open Agile Adoption techniques.
Is Agile a solution for this cost reduction and predictable deliver of replacement solution domain of the late adoption mindset? I believe they can see benefits of adopting the basic foundations of Scrum. Of adapting the underlying Extreme Programming techniques that power the Scrum framework. Yet the agility of the processes might be antithetical to the organizations purpose of delivering software.
A case in point: a client in the data management of health care actually has the policy of allowing their clients to pick and choose (ala-carte) the software development process aspects that they are willing to pay for. For example - the client may not wish to pay for the QA on a project, so the development group conceives that it is their role to deliver a software product without doing the QA. Or perhaps the client doesn't want to pay for the project management aspect, or the architectural analysis of the solution. Now this is an extreme situation - true. One that none of us would like to be in - but can this organization adopt the Agile mind-set? When the various directors and VPs of this organization say they want to do the Scrum/Agile thing - do they mean what I think they mean - or are we talking about very different purposes?
Alex Wissner-Gross - A new equation of intelligence - TED Talk
Agile Scout's SAFe Review
In a recently published article, A Product Owner’s Syllabus, I shared how we educate product owners in our company. A product owner’s job requires competence in a number of domains, as it turned out. There’s one more consideration that I want to highlight. It’s rather related to the environment where this product owner works, not to personal skills or knowledge. Sometimes, though, it’s quite hard to draw the distinction between personal skills and how those skills are influenced by the environment.3 Levels of Product Ownership
Product owners can act on the following levels:
Mix of innovative and market-driven
Why is it important to single out these levels prior to doing drills in narrow disciplines included to the PO syllabus? This helps the trainees realize the high-octave “why” of this work. They say that philosophy is the mother of all sciences. In the same fashion, knowing the very reasons of why a product exists at all is the necessary first step. This knowledge and reasons are very product-specific. That’s why I’m skeptical about all kinds of “certified” courses, because attending a course and taking part in abstract drills (such as the ones brilliantly mocked at in here) will not turn anyone into a mature product owner overnight. To me, the best credentials for a product owner would be the history of the product that this person owned or managed, at least for some time, and the thinking that stood behind their decisions. There’s no better learning than by doing.
Just as in my recent post, where I anchored our evolving as a company with the way we do visual process management, I will look back at the history of our product yet again. We’re cool big guys, because we can look back as far as 10 (!) years ago. Targetprocess 1.0 was launched in 2004. Targetprocess 2.0 was released in 2006. Targetprocess 3 came on the scene around 2012-2013. The 1.0 version was the minimal viable and marketable software for agile project management. Targetprocess 1 had 7 releases, from 1.0 to 1.7. Targetprocess 2 had 24 sub-releases, from 2.0 to 2.24. With Targetprocess 3, we released the version 3.0.11 last week, and the next release will be 3.1.The Market-Driven Suite and Innovation
Looking at the releases from 1.0 — 1.7, and 2.0 — 2.24 (click the hyperlinked words above), one can draw some interesting conclusions. Targetprocess progressed with the agile movement and with what the market wanted( I wish we had a decision sequence timeline to track this better). The 1.0 version appeared as a result of market-based thinking, because agile was a rising new trend back then, and our product owner and founder (who has the project management background) wanted to do a decent software for agile project management. Then, with time, the 2.0 version was released. This was a re-written software with completely new UI. The product owner sensed that the product needs a robust core and an improved UI, before any new features could be added. That was a strategic market-based decision. Then after about 8 years of following the market, the product owner hits the level of innovation with Targetprocess3. It is indeed an innovative project management software as it brings along a new paradigm in visual project management. I do not intend to go too deep into praises, I just want to show with this story that it takes 8-10 years for a product owner to become mature and operate on the level of innovation. Some product owners never get to this level. They implement the features that make their product more appealing to users, to outperform the competitors, or both. There’s nothing good or bad about it, just the way it is. It’s quite rare nowadays that a completely new product comes as “innovative”. Start-ups are mostly busy discovering smaller niches in the established market and filling them in.A Basic Drill for Newbie Product Owners
Well, a product owner may or may not reach the innovation level. Let’s get down back to earth. I have this list of questions ready for trainee product owners to help them exercise their minds in product-based thinking as they consider implementing new features:
How often will people use this new feature?
How many people will use it?
Will this feature address any particular pain of users?
How it will help users save their time, if at all?
Will it make any difference, or will users be just as fine without this feature in the product?
Will this feature make the product easier-to-use or more complex?
Will it help bring new business, or is it meant for established users, mainly?
Formulating such questions can be a good exercise at an internal company training. The road to success starts with one first step, and this simple drill might be a nice first move in a career of a product owner, who might become an Innovator some day.
Rally believes that for-profit business can -- and should -- be a force for social good. That means we join companies like Ben & Jerry's, Patagonia, Method, and Seventh Generation in measuring business success by the triple bottom line: people, planet, and profit.
Rally is part of a growing community of nearly 1,000 Certified B Corporations from 32 countries and 60 industries, working together toward one unifying goal -- to redefine success in business as being not just the best in the world, but the best FOR the world.
Rally just completed its third, rigorous B Lab assessment, demonstrating our positive impact on community, employees, and the environment. The B Corp model helps us benchmark that we are living up to our own mission and that we push it even further.
What makes Rally a Certified B Corp? Here are a some highlights:
- Giving back to the community. In 2013, following our successful IPO, Rally donated $1.4M of founding equity to charitable causes and created the Rally For Impact Foundation, which enables engineers to apply their skills and expertise for positive social change.
- Providing free Agile education. Rally is working with innovative social impact organizations such as Rocky Mountain Microfinance Institute, where employee volunteers provide Agile coaching, training, business planning and team facilitation. In 2013, our employee experts also delivered “Act Like An Agilist” courses to social entrepreneurs at the Unreasonable Institute and Impact HUB Boulder.
- Treating employees well. We were honored in 2013 as "Best for Workers," scoring in the top 10% of all Certified B Corporations for our positive impact on the people of Rally.
- Paying People to Give Back. Our culture of giving encourages employees to spend 1% of their paid time volunteering, as well as giving back to their community on their personal time. As a result, in 2013 Rally employees contributed nearly 4,700 volunteer hours, or almost 600 worker days.
- Encouraging volunteerism from day one. Beginning this month, when new employees go through Rally’s onboarding “boot camp” they spend two hours volunteering.
- Shrinking our carbon footprint. Rally’s products are primarily deployed as Software as a Service (SaaS), which minimizes the creation or shipment of physical goods and optimizes the energy-efficiency of modern data centers.
- Recycling and composting at scale. At our office headquarters in Boulder, Colorado, where we employ about 60% of our staff, we’ve partnered with internationally-recognized nonprofit Eco-cycle to recycle and compost 74% of our waste.
- Getting to work with pedal power. Rally’s Boulder and Denver offices have a large bike-to-work population, and we offer all Colorado employees a company-paid EcoPass for public transportation.
As a Certified B Corp, Rally supports the movement for business to play a leading role in providing social and economic benefits to the world while delivering great products and services at a profit. Values-led businesses like Rally deliver shareholder value, while building trust among our customers and partners that we are in service to the global community.
We have a shared responsibility: we are collectively striving for shared and durable prosperity. Let’s B the Change.Geri Mitchell-Brown
This scaling problem has been studied.
"In 1957, British naval historian and management satirist Northcote Parkinson [known for Parkinson's law: “work expands to fill the time available for its completion”] painted a cynical picture of a typical committee: It starts with four or five members, quickly grows to nine or ten, and, once it balloons to 20 and beyond, meetings become an utter waste of time – and all the important work is done before and after meetings by four or five most influential members."
Scaling up Excellence
Why Big Teams Suck by Robert Sutton is a Stanford Professor and co-author (with Huggy Rao) of Scaling Up Excellence: Getting to More without Settling for Less.
Studied in Academia"After devoting nearly 50 years to studying team performance, the late Harvard researcher J. Richard Hackman concluded that four to six members is the team best size for most tasks, that no work team should have more than 10 members, and that performance problems and interpersonal friction increase 'exponentially as team size increases'.”
Studied in the Military"Some organizations learn about the drawbacks of oversized groups the hard way. Retired Marine Captain and former U.S. Senator James H. Webb explained why the “fire team” – the basic combat fighting unit – shrunk from 12 to 4 during War II. Webb wrote in the Marine Corp Gazette that this “12 man mob” was “immensely difficult” for Marine squad leaders to control under the stress and confusion of battle. Coordination problems were rampant and close relationships – where soldiers fight for their buddies – were tougher to maintain in 12-man teams."
Studied in Health Care"A Harvard Business School study by Melissa Valentine and Amy Edmondson of a large hospital’s emergency department [...] The crowd of 30 or so doctors and nurses who staffed the department at any given time were divided into multiple six person “pods,” each led by a senior doctor or “attending physician.” After the change, information about patients flowed more quickly and accurately and personal relationships improved markedly. Smaller teams reduced confusion and discomfort about who to ask for help and updates."
I think the general lesson learned is to not scale up, because the systems and structures that created and support the current organization will not bare the stress of scaling up.
Some alternatives to Scaling Agile:Scaling Agile – the Easy Way by Arlo Belshee
Try to re-structure the organization in a way that doesn't require efficiency of scale to achieve the goal. For example WL Gore's organizational pattern a team based flat lattice.
Or Semco, "a Brazilian conglomerate that specializes in complex technologies and services. Semco is a self-managed company. Workers at Semco choose what they do as well as where and when they do it. They even choose their own salaries. Subordinates review their supervisors and elect corporate leadership. They also initiate moves into new businesses and out of old ones. The company is run like a democracy." -- Podular organization: a business within the business written by Dave Gray.
Lessons from Semco on Structure, Growth and Change
Try a fundamentally radical idea like Holacracy. "Holacracy is a real-world-tested social technology for agile and purposeful organization. It radically changes how an organization is structured, how decisions are made, and how power is distributed."
Take a lesson from the US Government's FBI Case Management system.Case Study of a Difficult Federal Government Scrum Project: FBI Sentinel by Michael James.
Before you consider the leading market agile/scrum scaling tool-sets like SAFe, DAD etc. try this alternative approach: Open Agile Adoptions by Dan Mezick author of The Culture Game.
“Scaling is actually a problem of less,” says Sutton in The Do’s and Don’ts of Rapid Scaling for Startups. “There are lots of things that used to work that don’t work anymore, so you have to get rid of them. There are probably a bunch of things you’ve always done that slowed you down without you realizing it.”See Also:
The Agile Late Majority has different needs
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?Bernoulli’s principle
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.
This incredible video of a Formula One pit crew in action has been making the rounds on the Internet lately. Have you seen it? The crew performs an entire pit stop in under three seconds, with no errors, working in perfect synchronicity -- like a “pit stop ballet.” Go ahead and watch, we’ll wait ... (it’s only 56 seconds, and safe for work.)
Watching this video got us thinking about the performance of Agile teams (hat tip to Agilista JessK.) Rally knows a little something about team performance thanks to the work of Larry Maccherone, Director of Analytics at Rally, and his Software Development Performance Index.
Using real, non-attributable data from the performance of nearly 10,000 teams, Larry’s analytics team looked at four dimensions of Agile team performance: productivity, predictability, quality, and responsiveness. What they found is pretty incredible evidence for how to optimize your Agile team performance.
To demonstrate, let’s use the F1 crew as an example. Each F1 pit crew mechanic has a distinct role, and performs only one job. In Agile terms, you might say that this crew has extremely low Work in Process (WiP.) And on an an Agile team, having fewer work items in process means that each item gets done faster. The amount of time that a work item spends in process is a measure of responsiveness. So lower WiP means faster time in process, faster time to market … and in the case of the pit crew above, highly responsive pit stops.
In Agile, teams with poor control over their WiP take nearly twice as long (see Time in Process on the Y-axis, above) to complete their user stories as teams with low WiP. This makes intuitive sense: as with the F1 mechanics, the more focused you are on just one thing, the faster you'll get each one done.
Lowering your WiP can have benefits besides responsiveness: teams with the lowest WiP have 4x better quality than teams with the highest WiP. When your job is to affix a tire to a car that’s going to drive more than 200 miles per hour, well … quality really matters.
But performance like that of the F1 crew comes with some costs. Though teams with low WiP may cut their time in process in half, and have one-quarter as many defects, they also have 34% lower productivity.
In Agile, productivity is measured by the number of user stories and defects completed in a given time period. Take a look at this NASCAR pit crew as an example.
NASCAR races allow a limited number of pit crew members "over the wall” during a pit stop, so each mechanic must be more productive. Changing a tire takes about 5 seconds, and each mechanic has to change 2 tires. While this crew may not seem as responsive as the F1 crew (its Time in Process is 13 seconds vs. under 3,) it’s much more productive.
Speaking of numbers: did you happen to count the number of mechanics on that F1 crew? There are a whopping 21 of them, standing around waiting for their car to pull in. By contrast, the NASCAR pit crew is limited to 7 mechanics. (The recommended size of an Agile team is 7 ±2.)
So what does this all mean?
- If your WiP is high and you’re at risk for missing a market window, then drive your WiP as low as possible by focusing on just a few things and getting them to market faster. In other words, make like an F1 pit crew.
- If your WiP is already well-controlled, however, consider your economic drivers. For example, if productivity drives your bottom line, don’t push your WiP too low. Instead, take more of a NASCAR pit crew approach. Balance is key.
Hungry for more?
- We’ve got our own videos of Larry Maccherone himself, explaining the team performance metrics.
- You can download the whitepaper if you prefer reading to watching; you can learn about the dimension of predictability in here, too.
- Lest you get carried away with the weight of performance metrics, make sure you check out the Seven Deadly Sins of Agile Measurement.
- Finally, stay tuned: if you're a Rally user, these metrics will soon be coming to a dashboard near you.
I’ve poked around the subject of visual process management in my previous articles, accentuating the complexity and non-linearity of software production process, and how a traditional Kanban board fails to visualize the diversity of organizational contexts and workflows. With that in mind, I’ve introduced a concept for a universal visual process management system that is capable to embrace this diversity and linearity on one screen, with flexible zoom-ins and switches, and called it Multiban.The Limitations of Kanban Board
Many software development teams suffer the limitations of Kanban board, at one point of their evolution or another. When a company grows, the scope of work grows as well, the structure of the company and of the teams, that it is comprised of, are changing, and what if one Kanban board is not capable to accommodate those changes? What if a large company is working on a suite of products, and a 1 team-only Kanban board cannot show the bottlenecks that are out-of-the scope for this team, but still influence its work? Or, what if the 1 team-only WIP’s are not relevant, because a suite of products is a sum of components, where each team’s work is a component of the whole product, and WIP’s and value streams have to be balanced on a wider scale, beyond the scope of one team-one project board?
We had to find answers to such questions. In 2012, Michael Dubakov published the Our Development Process: 50 Months of Evolution article. The changes that have occurred over 2012-14 are not covered there, but it still shows how our needs in visual process management were addressed in parallel with the changes in our company setup. Keep in mind that we are a very special company. We develop Targetprocess, agile project management software, since 2004, and we have an advantage because we are free to choose how to shape our product to make it respond to the changing needs and structure of our organization better. Over the last 5 years, we’ve been consistently working to make our tool more visual and more powerful. I will single out the major landmarks.2009: Switch from Scrum to Kanban
In 2009, we switched from Scrum to Kanban. By 2009, we’d been doing iterations for 3 years, and iteration development worked great when Targetprocess was a young product that needed to gain the critical mass and stay alive. Then, we realized — and that coincided in time with the uprise of Kanban — that we’d be better off reaching our goals as an organization if we practice development with Kanban. If you’re interested, here’s an in-depth story of the reasons and the production context that we had back in 2009. With our hands-on attitude, we didn’t linger with it, and implemented Kanban support in our project management tool. That’s how our Kanban board looked back in 2009 (one team-one project):
We implemented this Kanban board to cater both to our own needs, and to the needs of our customers.2010-11: Kanban is not enough. How about TeamsBoard?
While the major reason for our move to Kanban in 2009 was the change in the product development dynamics (the product matured, and we needed to switch to the “add features” mode), the major change in 2010-11 was the switch from one team to many teams, as we realized that this setup works better for the “add features” mode. The count of feature teams is not fixed, it changes depending on which features we’re doing at the moment. So, we felt the need to visualize the work of many teams on one board. Hmm. That’s not what a simple Kanban board was able to offer us. That’s why, as hands-on as we are, we poked around and came up with what we can now call the forefather of Targetprocess 3. Take a look at TeamsBoard, edition 2010:
This board doesn’t look too fancy now, in 2014, but back then it was surely a step ahead compared to a simple Kanban board. One can see backlog, and work in progress for many teams. If some states had their WIP limit exceeded, the TeamsBoard would show it. In the screen above one can see that WS team had the bottleneck with 3 bugs and 1 user story resting in the Coded state. Then this work of testing could be shared with the other two teams. The TeamsBoard also allowed zooming in on each team, and what they do, by person.2012-14: Targetprocess 3 and Fine-Tuning Process Visualization
Then, as we realized that sky is the limit, and visualization has enormous potential for project management, and for our own needs, we moved forward with the concept of the tool where anything can be visualized, depending on the changing dynamics and goals of a company. The fundamental idea is to offer a flexible tool that adapts to any process and follows any organizational changes. The other fundamental principle is the switchability of visualizations. We do not have stakeholders who tell us what to do and what to implement next. Our feature teams and our customers are the stakeholders. They tell us where else they need flexibility, and our backlog is formed based on those needs. We run recurring UX Process Visualization sessions, to see where else do we have yet to make room for more visual flexibility. We stepped aside from the traditional Kanban as the visual process management system long ago, and what we are now having is Multiban a visual process management system that supports any development process, for any number of teams and any number of projects, with cross-team and cross-project planning, using timelines for roadmapping, views as reports, etc. This screen from Targetprocess 3 is related to the good old Kanban of 2009 only by its board-ish looks, while in reality it is a switchable slate of views, zooms and perspectives.
It’s time to say a few words about Multiban now. Perhaps, the fastest way to explain how Multiban differs from Kanban is to use a metaphor. Multiban can be compared to the 17-inch interactive screen as in Tesla luxury electric cars. This awesome screen is a one-spot customizable dashboard for media, navigation, communications, cabin controls and vehicle data. Multiple Kanban boards for one suite of products (or a related suite of features, as in our case) can be compared to putting many touchscreens in the car, or even to using plastic controls for each of those functions. Would a driver feel more comfortable using one smart touchscreen? Or many simple screens? Or many knobs? It depends. For one thing, no doubt, the super-fancy touchscreen would require a learning curve. If a driver is OK with various controls, and if they do not depend on each other, then probably the car and the driving will be OK. Switching back to knowledge work: too many things are interrelated in software development, and losing track of those connections can have a bad impact on the way the work is done . It’s hard to keep everything in mind, and use visual board as a polished parade version of a development process. Multiban, as the visual process management system, is presented by a set of views, reports, controls and boards that comply with any diversity, and any complexity of workflow, or organizational structure. Targetprocess 3 is the only digital tool that supports Multiban at the moment. The concept of Multiban is the by-product of our organizational evolution, which dictated the need for evolutionary changes in our visual process management. Now we are ready to share what we’ve learned and implemented with other organizations that have been evolving, or will be evolving, in a similar fashion.
Immer wieder frage ich mich in meiner Rolle als ScrumMaster: „Was kann ich dafür tun, dass mein Team schneller wird? Wie kann ich es anspornen?“
Was sind Motive, um schneller zu liefern? Unterscheiden wir zunächst zwei Kategorien der Motivation. Die intrinsische, also die Motivation von innen heraus, und die extrinsische, also die Motivation von außen. Hier einige Beispiele:
- Die Arbeit und ihr Ergebnis begeistern mich.
- Das Ergebnis hat für mich persönlich einen greifbaren und spürbaren Nutzen.
- Angst um den Arbeitsplatz/vor den Konsequenzen bei Verzug, auch ohne spürbaren Druck von außen
- Ich weiß, welchen Anteil/Beitrag ich leiste.
- Ich weiß, wohin die Reise geht.
- Ich bin innerhalb eines für mich guten und nachvollziehbaren Rahmens selbstbestimmt in meinem Handeln
- Druck von außen (Chef, Projektleiter etc.)
- Prämienzahlung bei Termintreue und stimmiger Qualität
- Anerkennung vom Chef/Vorgesetzten.
- Konkurrenz anderer Teams/Projekte/Unternehmen
Idealerweise arbeitet jemand effizient und liefert entsprechend schnell und in guter Qualität, auch ohne dass wir etwas tun. Das Leben ist aber nicht immer ein „Ponyhof“ und so sind doch immer wieder einer „Beschleunigung“ von außen und Motivationsspritzen durch den Scrum Master nötig. Ich möchte also die Frage stellen: Wie motiviert ihr euer Team? Oder. Wie bringt ihr das Team dazu, vielleicht sogar für euch zu rennen? Hattet ihr schon einmal einen Team Lead/Chef/Vorgesetzten, den ihr so sehr geachtet habt, dass ihr schon aus diesem Grunde für ihn oder sie gerannt seid? Eine ideale Situation, oder?
Als Geschäftsführer habe ich die Erfahrung gemacht, dass genau hier ein wichtiger Hebel liegt. Es steht zwar in keinem Buch geschrieben, aber der ScrumMaster ist in meinen Augen auch für die Stimmung im Team zuständig. Wie heißt es doch so schön: Der Fisch beginnt beim Kopf zu stinken. Oder: „Zeig mir dein Geschäft und ich zeig Dir deinen Chef.“
Tun wir also etwas dafür, dass das Dev Team gerne liefert. Sorgen wir für Stimmung und dafür, dass die Mitglieder gerne zur Arbeit kommen und gerne in diesem Team arbeiten. Genau dafür braucht es ja die berühmten Soft Skills, wie die Fähigkeit, Konflikte zu lösen oder als Schlichter und Moderator zu agieren, um Frust zu vermeiden etc. Warum nicht also den Witz des Tages einführen oder ein regelmäßiges Teamfrühstück durchführen? Auch mehr oder weniger große gemeinsame Teamevents können helfen. Dies sollen keine pauschalen Allheilmittel sein. Jeder sollte herausfinden, was dazu führt, dass ein Teammitglied sich noch wohler fühlt. Wichtig ist jedoch, dass Konflikte gelöst und nicht unter den Teppich gehören. Machen wir uns bewusst, dass Stimmung immer herrscht, ob wir sie nun gerade sehen oder auch nicht. Aber sie ist vorhanden und sie bewegt und leitet unsere Teammitglieder. Machen wir sie also lieber sichtbar. Beispielsweise durch eine Frage danach in der Retrospektive. Eine Freude für alle, wenn sie ohnehin gut ist. Eine Chance jedoch, wenn sie gerade nicht gut ist, denn sie wirft die logische Frage nach dem “Warum” auf. In der Retrospektive des vergangenen Sprints fragte ich alle Mitglieder nach ihrer Stimmung auf einer Skala von 1-10, wobei 10 die Bestnote war. Im Durchschnitt lag unsere Stimmung bei wundervollen 8 Punkten. Ein tolles Ergebnis, aus dem ich ableitete, dass diesbezüglich keine dringenden Maßnahmen nötig waren. Und vielleicht könnt ihr euch vorstellen, was dieses nun transparente Ergebnis in den Gesichtern der Teammitglieder bewirkte.
Fragt euch am besten also selbst nach den Gründen dafür, warum ihr gerne in einem bestimmten Umfeld arbeitet und lasst euch davon leiten. Frei nach dem Motto: Ich behandle die anderen so, wie ich selbst gerne behandelt werden möchte.
- Scrum Essentials: Die sieben Fragen der User Story
- Der ScrumMaster als Dienstleister
- What´s S.C.R.U.M. ?
Natalie Warnert (@nataliewarnert) blogs at Confessions of a New ScrumMaster. Here she is, talking about dating Agile.
So I’m being an Agile player. I’m dating a few different versions of Agile to see which works best while trying to keep it from the other methods I’m test driving. Don’t tell Scrum that I was scoping out Kanban. Don’t let Kanban know I made a date to get to know TDD better. How can I help the team decide which is best when there are so many options to consider? A hybrid approach can sometimes work, but under some corporate guidelines the relationship needs to be with one or another exclusively, not multiple. It’s all about exclusivity in this corporate Agile dating world. (I plan on posting a subsequent post exploring the non-exclusive relationships and hybrid approaches to this in the future – check back).
Honestly I’ve only tried each for a short time, so it could be too soon to tell. How long do you date one until you decide to make your relationship and commitment public? There is the get-to-know you phase where you’re just trying to figure out what each methodology is about, what they stand for, and what they work best for. It has to be determined if they are compatible with the team and project and if the relationship will work in the future.
Once you have an idea of which you want to commit to, how can you be sure? Should you keep the others on the line in case it doesn’t work out? If there are a few things that don’t work in one, do you try to tweak those things at the risk of losing the integrity of the methodology itself? What are the long term consequences of not being able to make a commitment? Obviously methodologies don’t have feelings but teams do, and how do you help the team to determine what is best without causing them unnecessary pain and confusion?
Does the team settle for what works “well enough”? Where they and the stakeholders can be happy? But what is to say there is not more happiness out there to be found? That hopefully should be found as the team improves and continues to inspect and adapt for what works best for them. There are things in methodologies, like people, that won’t change in relationships, but there are other things that can and will change as the relationship grows and matures. Goals get more defined, it becomes more comfortable, but there will still be and should still be ups and downs. That is how the relationship continues to improve and get stronger. Maybe at some point if the team or project changes too much the relationship will need to be ended, but that shouldn’t be looming overhead. If it ends, it simply means the team and the methodology grew apart and will need to look to start dating again.
It’s okay to be an Agile player at the beginning but in some corporate PMO run environments, the non-exclusivity does not work for very long. It’s best to go in with your eyes open, learn as much as you can quickly, and help the team to make an informed decision for what methodology they should have a commitment with.
This post first appeared as I’m being an Agile player on Natalie’s blog in June 2013.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]