SAFe (Scaling Agile Framework) is gaining in popularity. Ron Jeffries recently attended a SAFe training session and has written a great review. I particularly like what Ron says about the idea of being properly Agile:
SAFe will be successful in the market. People will benefit. They just won’t benefit nearly as much as they might if they set out to do things in a fashion that truly supports Agile Values and Principles.
SAFe is good. It’s just not good enough. It provides some benefit, but endangers an organization’s progress toward really high functioning. As someone who has been in the Agile movement since before it started, I do not like it. It’s fast food. You can do better.
Neil Killick seems to have even stronger opinions about SAFe, and is quite direct about them. I like what he says in one of the comments on his blog post:
So you can go the SAFe path or the Scrum and Agile path. All you need to do i[s] figure out how big a cliff you want to deal with down the road.
I don’t personally have any experience with SAFe so I won’t make any big claims about it either way. However, I do appreciate that the popularity of SAFe, like the popularity of Agile/Scrum* will probably lead to studies showing modest qualitative improvements of 20% to 40% increases in productivity. Is this just the Hawthorn Effect at work?
When I help an organization with Agile principles and methods, I hope and expect dramatic measurable improvements. Sometimes this results in people losing their jobs. Sometimes this means people have nervous breakdowns. It can be very painful in the short term. SAFe, by it’s very name, seems to be anti-pain. That doesn’t bode well.
Here are a few other interesting links to information about the Scaled Agile Framework:
* There is no such thing as “Agile/Scrum” but that’s what lots of people call Scrum when they don’t do Scrum properly.
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.
The WholeHearted Manifesto consists on one value statement:
We Value People. (Period)
People are the driving force behind getting results. This is the secret recipe for success.
We value all people. Our customers. Our peers. But most of all ourselves.
It would be a mistake to think this is fluffy bunny stuff. It’s not. It is the hard stuff that makes all the difference.Wholehearted Principles
The principles of the Wholehearted Manifesto are:
- People happen. Not right, not wrong. They will amaze you.
- Awesome outcomes emerge from people who truly connect.
- Collaboration is our oxygen: we co-create environments for people to flourish and grow.
- We all are on a unique journey and help each other along the way.
- We love and celebrate people for who they are.
- We are open and honest.
- We ask for help before we need it.
If you have any comments, suggestions, or enhancements – please add them on the manifesto page. Help make a difference
If this message resonates with you – please go sign the manifesto. And please share the message. Let’s move towards a better world.Acknowledgements
The manifesto spontaneously emerged during an intense, emergent collaboration session I had with Olaf Lewitz & Christine Neidhardt. We were not seeking this, it just arrived. So I imagine that many other people must be thinking the same thing. So this is a shared idea – not ours. Not anyones.
A wonderful group of people came together to help build the Wholehearted Principles at Play4Agile in Ruchersbach, Germany. Many thanks to:
- Alexey Krivitsky
- Andrea Grass
- Ari-Pekka Lappi
- Christine Neidhardt
- Ivana Gancheva
- Jan Weinkauff
- Jerónimo Palacios
- Michael Sahota
- Mikko Mannila
- Olaf Lewitz
- Rolf Dräther
- Sandra Warmolts
- Sebastian Lang
- Silvana Wasitova
We would also like to thank Brene Brown who has greatly influenced with her wonderful books and TED talks. She introduced the term “wholehearted” to describe people who are able to fully love themselves and bring joy to those around them.
- The Business Case for an Authentic Workplace People are messy: they have personalities and emotions. In this...
- Create Authentic Connections with Influence Maps (Joint post with Olaf Lewitz - Temenos Series) In the course...
- Temenos – A Workshop for Healing, Connection and Relational Flow (Joint post with Olaf Lewitz) What is Temenos? Temenos is also...
Related posts brought to you by Yet Another Related Posts Plugin.
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 firstname.lastname@example.org
[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).
By Kevin Meyer
Specifically, in March of 2009 Gemba Academy was born. We had no way of knowing whether there would be interest in what we were doing… but we started nonetheless. We wanted to create an easy and affordable way to deliver high quality lean training to the masses.
Now, here we are five years later, with over 500 lean and six sigma training videos used by over 2,000 companies around the world.Growing Up
We’ve made many mistakes over the years, but we've taken the opportunity to learn from them. We do our very best to practice what we preach… when we make a mistake we learn from it and try to understand the "why" before jumping at the easiest fix. We try to do the same with successes.
In other words, we’re constantly doing our best to practice continuous improvement!
I know there are all kinds of statistics out there regarding how many companies fail to succeed after a year or two. I don’t know how much of that is true… nor do I really care. But it's been five years...! And we feel like there's even more opportunity today than there was the day we started.Thank You!
But, most importantly, I’m thankful for current and past customers of Gemba Academy. We’d obviously not be around without you. It is very fulfilling helping others learn, and gratifying seeing the success they then create.
So, from the bottom of my heart, thank you!Celebrate With Us!
Lastly, as we’ve done every March, we’re celebrating Gemba Academy’s birthday with our free DVD promotion.
So, if you’re interested in learning more please head on over and check us out! We’d be honored to earn your business.
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.
In Scrum and other Agile methods, a common way to manage feature requests is with User Stories. I’ve been teaching people about User Stories and doing workshops with teams for a long time. Out of that work, I’ve created a very simple PDF User Stories and Story Splitting reference sheet that might be handy. Please feel free to download it and share it. This document is something that I explain in-depth in my Certified Scrum Product Owner training seminars.
There are a number of sites out there that include some details that are left out of the reference. Please see, for example, “Patterns for Splitting User Stories” by Richard Lawrence. See also the great foundational article on “INVEST in Good Stories” by Bill Wake.
- Encourage multilateral communications and dialogue among peers and between employees and leaders. Offer workers a shared sense of ownership in company goals and mission—encouraging employees’ sense of voice, position, significance and purpose.
- Establish strong company values that employees can understand and know how to practice—increasing their sense of belonging, purpose and security.
- Set challenging but achievable goals—to increase employees’ sense of challenge, learning and autonomy.
- Shift the focus from hierarchy to community—connecting employees to one another in ways that empower them and increase their sense of belonging, connection and security.
- Ensure that you are adequately recognizing and rewarding individual and team achievements as they relate to shared values and goals. Make sure those rewardsrespect individualism and include choice. This will increase employees’ sense of fairness, purpose, recognition, belonging, and choice.
“A man who trusts nobody is apt to be the kind of man nobody trusts.” - Harold MacmillanAs I look at the list, I agree with all of the statements. I don't think it's a comprehensive recipe, but it's solid advice. The sequencing of the list jumps out at me as a tad off. I'm not sure Darcy is suggesting things be done in this order, but enumeration implies some form of priority or sequence. Assuming there is a priority to this list, I'd put strong company values first, followed by shifting focus from hierarchy to community. These two are the foundation of the remaining three items.
I encourage you to read Darcy's article. And please share your thoughts by commenting on this post.
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
This weekend I was forced to throw away a cardboard box. So what, I hear you think and I agree, but it being Sunday and me being in a hazy reflective Sunday afternoon state of mind (nono, no alcohol yet) and the box being the specific cardboard box it is (or rather was), I started thinking of the box’s significance for the future.
This is a picture of the cardboard box in question in it’s final state just before it got thrown into the recycler.
As you can see it’s got a large sticker saying ‘Oracle’ above the word ‘KABELS’ written in my clunky handwriting. The word kabels doesn’t really matter, it just indicates the box was used to hold various lengths of electrical wire. Next to the Oracle sticker and the kabels text you’ll see a partially torn label from ‘Donelly Documentation Services’ in Ireland. It is in fact the box that was used to ship my very first set of Oracle manuals (for release 6 of the Database and probably 3.0 of Forms and more contemporary tools) in April 1992. Since that time the box used to hold manuals for consecutive releases of Oracle products stored in the trunk of my car. I used to take them with me to customers on various assignments.
Later I left Oracle and the box was used in two removals (it was of remarkably sturdy material) and ended in my garage holding bits and pieces of electrical wire.
Last Sunday I dragged it of a shelf and finally it’s corners tore spilling cables all over me and the garage floor. Exit box.
This is getting into a long winded intro, I know but there is an interesting similarity between the box and the changes in the tools I use in my professional life. After starting as an Oracle specialist I worked on Java software which became Oracle software later of course. Last Sunday I realized I was writing Java-ish software again for the first time in about a year. Android, but still.
I haven’t been using any of the software I grew up with for quite a while now. Relational databases are being replaced by key-value stores and even flat files. JEE servers changed into Spray and Akka. Scala and functional and reactive programming constructs rather than object oriented Java and its bolted-on lambda extensions. Angular-JS instead of, hey wait a minute, that looks like a fat client all over again (wondering what’s going to happen to it). Server software I work with is easy to install, unpacking a zip file instead of 500+ pages of manual guaranteed only on an outdated Linux version. Modern software runs on simple Linux boxes instead of high end hardware with 7 digit price tags. New and innovative solutions replace software with slow release cycles. Open source is definitely leading the industry.
I wonder, does the end of the box forebode the end of a whole class of software? And like the cardboard box, will some bits and pieces come back in other products? I’m just hoping that it won’t take 22 years to get rid of the last generation of software.