[Originally published on ThePeoplesForum 8/5/13]
The previous post Scrum: a 5-step guide for managers was (quite rightly) criticized for not describing Scrum. It was never intended to. In the text I describe the five steps as being for “managers and executives for starting a new Scrum process”. The title was intended to challenge, to have people ask, so what is Scrum?
Scrum, clearly, is the thing defined in The Scrum Guide, a lightweight document, laying out the process, roles and artifacts of Scrum, and describing the value it offers. It is—happily—very low on prescription, beyond prescribing the basic Scrum framework. There is little in there to take issue with, and actually little that has changed from original Scrum. The problem is, with this and most of the books on the subject, sparse attention is paid to the environment in which we try to implement Scrum. To me this is key to success.
I recently witnessed a team implement at least the first four of the five steps I recommend. They were not “doing Scrum” and yet were closer to the values we seek with Scrum than many teams I have witnessed struggling to make the process meaningful with members in different locations, no clear product vision, team members working on different projects, being driven (and driven crazy!) by the electronic tracking tool of (someone else’s) choice, with all its rules and limitations. Scrum can sometimes create more pain that it relieves.
Teams that are not supported—environmentally, humanely, systemically—to do Scrum, will do Scrum very poorly. Teams that are so supported may not actually end up doing Scrum at all, but will likely have better results. This is my experience from the past nine years.
So my “5 steps” are intended to have managers and executives understand the necessary conditions for inspiring an effective, engaging process, whether that’s Scrum or something else. With such conditions met, I would usually recommend something that looks very much like Scrum, with perhaps a more continuous flow model á la Kanban. As always, context will determine the detail.
And if anyone doubts my own definition of Scrum, or feels it is out of line with The Scrum Guide. Please read Simple Scrum, an essay written in 2009, which still accurately reflects my understanding of Scrum.
Original comments can be seen here
[Originally published on ThePeoplesForum 7/31/13]
Scrum is really very simple. Here’s a 5-step guide for managers and executives for starting a new Scrum process.
- Start with a clear product vision—and a visionary guide (PO).
- Establish a co-located, cross functional team whose members between them have all the skills necessary to build the product. 
- Create a space for the team to work in, with plenty of wall space, whiteboards, index cards, tape and sticky notes.
- Introduce the team to their stakeholders and users.
- Get out of the way.
Even without any Scrum training, you’ll find that your team is 75% of the way to having a highly effective process. The continuous improvement part will emerge, because people working in an autonomous way, with clear purpose, want to be the best they can be.
Starting Scrum is really is as simple as this. Why do we make it so complicated. Why is each of these steps so hard—especially step 5?
 Start with the smallest possible team. Let the team determine who/what skills they need to add as they progress
Original comments can be seen here
See also Scrum: the necessary conditions
I hope you are doing well and I am providing value to you with these posts (I know your time is valuable).
I am working hard at keeping them ON TOPIC (Scrum) and appreciate all the e-mails, calls, and comments when I post out here. You are awesome. Thank you.
The last posting I wrote (been a few weeks — bad mike) I wrote about ASKING FOR HELP and FOCUSING.
These are two key elements I use to get past that concept of ANALYSIS PARALYSIS.
Do they work for you?
What else helps you get past it?
I know I told you I’d write about scaling scrum — because that is really becoming popular today.
Thing is… it’s NOT a new thing. It’s just getting more and more popular as people THINK other competitors (or organizations) are successful scaling Scrum.
Here is a basic question:
What does “Scaling Scrum” mean to you?
For years, I’ve been recommending to SLOW DOWN and #DELIVER something.
One. Thing. At. A. Time.Enterprise Scrum: Ignore THIS Advice and Fail
What does this have to do with Scaling Scrum (or Scaling Agile)?
Think about how tough it is to start a Scrum project in a large organization… heck… in ANY sized organization.
Do some google searching on something called SAFe (TM) (Scaled Agile Framework). Seems like it’s gaining market traction.
There are lovers and haters of the technique.
Some people called Scrum snake oil.
Some people are calling SAFe snake oil.
For me… well… you know by now I recommend people get good at Scrum before trying to scale it.
And. That’s me. Experience talking.
My recommendation is you READ MORE and LEARN MORE about it.
I have and will continue to do so (yes, I attended a 2 day powerpoint festival of reading slides to me).
Do your due diligence… READ about it.
Instead of getting stuck in analysis paralysis about where to start and how to start (big or small) — START.
In the original article, I shared an illustration of the levels of team maturity:
I described to Randy, how the ScrumMaster role is meant to help teams reach higher levels of maturity by, at first, directing less and then delegating more. Randy then drew the following diagram (it was, literally, on a Starbucks napkin so I've redrawn and added it to the diagram above):
The diagram shows the relationship between a leader in the SI model and the team, based on their maturity. This diagram resonates because it matches the formations you'd observe in a Daily Scrum based on the maturity of the Scrum Team.
Scrum attempts to bootstrap a Scrum Team into the "high supportive behavior" side (top half). Very often a studio's culture will be more directive going in, and you'll initially find teams reporting to the ScrumMaster, who is running the meeting (the "Coaching" quadrant in the upper right) at the center of a group of developers. Over time, a good ScrumMaster will improve their facilitation skills and support (upper left quadrant) the team as an equal member, standing as a part of the team's circle.
As a Scrum Team develops their maturity and becomes more self-organizing, the ScrumMaster will delegate more of their day-to-day duties, but always observe and support the team (lower left quadrant).
Any team that finds themselves in the lower right quadrant is not "doing Scrum" yet.
We like to say that RallyON is not your typical user conference: you won’t sit and listen to a bunch of speakers drone on and on, then have to weave between advertisements and vendors in the hallways. Instead, RallyON is your chance to get actionable advice, inspiration, and best practices from the leaders, coaches, champions, and developers who make up the Rally community.
Likewise, the Rally For Impact Scrimmage -- preceding the conference on Sunday, June 8 -- isn’t going to be your typical sit-and-listen conference event: no way. Intrigued? Keep reading.
The Rally for Impact Scrimmage is a fast-paced, collaborative, afternoon event that lets RallyON attendees help entrepreneurial nonprofit organizations solve real-world problems. Rally For Impact is Rally Software’s corporate social responsibility initiative, and in addition to protecting the planet and serving our communities, we also work to mobilize “Citizen Engineers.”
This scrimmage gives you a chance to be a Citizen Engineer for a day. Switch gears for a while and do well by doing good. Collaborate with a team to come up with innovative, technology-driven ideas for nonprofit organizations making a dent in some of the world’s toughest problems. Have fun AND learn rapid prototyping methods you can take back to your own company.The Event
You’ll learn about rapid prototyping directly from a master: Tom Chi, Experience Lead at Google X. Rapid prototyping is a methodology designed to save time and money by quickly collecting and integrating user feedback on ideas for new business models, marketing messages, products, and services.
Handpicked nonprofit organizations, who are tackling tough social problems around the world, will each present a compelling challenge their organization is facing or a new idea they're itching to test. Each challenge will require a Citizen Engineer approach — using technology to solve problems with environmentally, economically and socially responsible solutions.
Next, you’ll join forces in small teams to offer your ideas, skills, and creativity to iterate on the organization’s challenge -- using your newly-acquired rapid prototyping knowledge.
Facilitators trained in Lean and Agile practices (as well as cat-herding) will keep each team on course throughout the day. Snacks, happy hour, and dinner will be provided to keep the juices flowing.The Buzz
What do people who have “scrimmaged” before say about the experience?
“After the scrimmage I used rapid prototyping at a staff meeting. And what I saw for the the first time was 100% intellectual and emotional engagement for the entire meeting”
“We are still reeling from all the buzz and excitement from the Scrimmage. We can’t wait to bring this design approach to our teams and present all the learning we experienced to the entire organization.”
“It was awesome to have the opportunity to work on real organizations’ real-time challenges, as opposed to hypothetical situations. I will quickly add the philosophy of rapid prototyping to my own approach to idea development.”
If you’re planning to attend RallyON and you’re ready to switch gears and become a Citizen Engineer for a day, register now to join us on Sunday, June 8th, as we Rally For Impact.
What is the first thing that comes to mind when we hear the words: enterprise software? Most likely it’s something bulky, cumbersome, weighty, hard to use, and something that alludes to the drudgery of a job where software seems to block our productive flow, as opposed to fostering it. You might be able to compare it to being in the middle of some fun activity, such as hanging out with a new love interest, and suddenly your ex walks in and throws a stern look your way, making the smile slowly slip away from your face.
Dull user interfaces (UIs) have lost their standings to consumer and entertainment apps that are slick, streamlined and provide fresh content at the swipe of a finger; but enterprise software will not surrender. At times it even seems that these dinosaur-like UIs will never disappear, begging the question: what will finally make them extinct?
Mockery aside, much talk has been going on for some time about how uncomfortable UIs of enterprise software are, and how vendors should start producing more personable UIs for it. No “should” in this world will turn into action, unless there’s some propelling momentum that will make it happen, and that’s exactly why we need to make these improvements.
If we take an X-ray look into the heart of the matter, why do we need a better UX? Is it for pleasure, aesthetic enjoyment, or for the feel of comfort and continuous flow? What is the ultimate element that will dictate development of a better UX?
This primary incentive is called the need for speed. We’re moving away from the era of decade-long projects and yearlong rollouts of IT infrastructures, with obnoxious RFP-based adoptions pushed down the pipe from the top of an organization. Companies that use enterprise software want it to be flexible, adaptable and quick to update, in tune with fast-changing social, technology and business trends. Enterprise software vendors will inevitably have to address these needs and deliver a better UX, making user action flow easier and more intuitive, as well as shortening the times required to retrieve all kinds of reports from the enterprise Big Data.
Focus on visualization would be the essential prerequisite for this “accelerated” UX. The enterprise software of 2014 and beyond has no room for slowness, and UX in enterprise applications is a part of a bigger picture involving many facets. In a nutshell, feedback-based development is turning mainstream for enterprise companies, who demand faster rollouts, faster scalability, faster adoption and ease-of-use. There’s no time for pompous presentations or heavily loaded trainings, where learning how to use a software is similar to musing over scholastic text.
If there’s any example of a positive UX development in the enterprise world that would be Google, of course, with their cloud services that have always offered a smooth UX. Another example that comes to my mind is Salesforce. They make a genuine effort to make UX better for their end-users. They improved their contextual help, making it easier to find answers to “how to do what” questions, and did a face-lift to the UI. Considering the fact that Salesforce is the baby of the 90’s, it’s become generally cleaner and easier-to-use, both for people who enter the sales data, and for the executives who work with the reports generated from this data.
Now, if Google and Salesforce are marching ahead as the pioneers of this enterprise UX movement, how about the mammoth companies? What is the propelling momentum that would finally deliver a slick UX to an average enterprise software user, be it ERP, supply chain management, or project portfolio management?
Enterprise startups are the fireballs to ignite these changes. An enterprise start-up is a company that would create a new generation of easy to adopt, easy to roll out, and easy to use enterprise software, to help organizations get the most of their Big Data, from an analytical perspective, and support adjustments to daily operations, fast. In the mid-2000’s we witnessed an outburst of start-ups that bent over backwards to entertain the hell out of everyone. Start-ups at that time did photo sharing, social sharing, or gamification. But we only have so many resources and time for entertainment.
Some people do not like to overshare, especially in the workplace. Teenagers and young people spend a lot of time with entertainment apps, but they’re not the ones who spend money on software. What’s more relevant for software providers are the serious companies who are ready to pay for new, nice, crisp, usable and fast enterprise products. With the security and reliability of cloud improving, startups would be better off if they apply the power of their genius not to some viral dating app but to a software that would help people do work faster and with comfort.
It may take years but fresh start-ups will shift the paradigm in enterprise UX, emerging as the competitive power to old-school companies, so reluctant to weed their overgrown gardens. It reminds me of the Newton’s first law of motion: “An object at rest stays at rest… unless acted upon by an unbalanced force.” In the case of enterprise UX, this unbalanced force — read, new technology (cloud and mobile) + changing business and social environment (need for speed) — requires start-ups to champion this change. The ball is already rolling.
It won’t help to bombard established enterprise software companies with calls to update their UX and make it more usable. In most cases, they would weigh the costs of a UX face-lift vs. gains from new business and/or keeping old clients, and decide against it. Things will change as this new unbalanced force, the enterprise start-ups, come into play. The conservatives would then have to reckon with them, and either re-invent their identity, steering the updates needed for their software (which is not an easy thing to do), or step out of the game.
*This piece was featured in @Wired on March 28, 2014
Der Aprilscherz ist beliebt wie eh und je. Doch während man im Privaten nach wie vor auch sein liebstes Gegenüber genussvoll ins offene Messer laufen lassen darf, lassen die meisten Medien dieser Tage eine geradezu panische Angst erkennen, man könne ihre ohnehin zumeist recht harmlosen Aprilscherze auch nur für Augenblicke ernst nehmen. Zeitungsmeldungen im schnellebigen Internet werden mit einem durch Kursivierung korrekt als redaktioneller Hinweis ausgewiesenen „April, April“ unterschrieben, Nachrichtensprecher erklären dem erstaunten Zuschauer mit geschäftsmäßigem Lächeln, er sei vermittels des eben gesendeten Einspielfilms in den April geschickt worden.
Ganz unzweifelhaft ist das Schönste an jedem Aprilscherz doch der Moment, in dem man mit einem herzlichen „April, April!“ sein Opfer darüber belehren kann, überhaupt ein Opfer zu sein. Wer labt sich nicht gerne an dieser ergötzlichen Ungläubigkeit, garniert mit einem Quäntchen peinlicher Berührtheit? Aber dazu muss der Scherz doch erst einmal glaubhaft gemacht worden sein! Das ist doch der Witz am Witz! Hier ist von Stunden, vielleicht nur Minuten die Rede, die es zum Einsickern der Fehlinformationen in die Opferhirne braucht.
Man mag in aller Breite und Ausführlichkeit über die Ursachen dieser Entwicklung im öffentlichen Raume raisonnieren, im Endeffekt aber wird es sicherlich darauf hinauslaufen, dass an verantwortlicher Stelle die akute Sorge besteht, irgendjemand könnte sich ohne unmittelbare Scherzaufklärung möglicherweise in irgendeiner Weise auf den Schlips getreten fühlen. Was aber tun?
Auf Scrumdeutsch: Commitment muss her! Wozu ist denn ein witzloser Scherz gut? Wer andere in den April schicken will, muss auch die Möglichkeit verantworten können, dadurch nicht nur positive Reaktionen auszulösen. Das ist im Voraus zu bedenken: Was für einen Scherz will ich haben? Wie wird er durchgeführt? Was will ich erreichen? Doch ist der Plan einmal gefasst und die Entscheidung getroffen, muss die Sache konsequent durchgezogen werden, denn jemanden fast in den April geschickt zu haben, ist genauso viel wert wie fast funktionierende Software oder ein fast fahrendes Auto.
- ScrumAlliance introduces Examination for CSM and CSPO
- 15 Minuten sind 15 Minuten
- Chinesen essen doch Reis :)
Interested in knowing more about what the Drama Triangle is all about? Dillon Weyer of Scrum Sense discusses the Drama Triangle and how it can be used to help deal with team conflict and problem solving. Follow this link to find out more….. Kanban Foundation Level Training There are only THREE seats remaining on our Kanban Foundation Level Training […]
It’s been more than 10 years since I last worked with him. He’s a lovely guy, full of humility and kindness. It was a pleasant surprise to work with him again. Thankfully, in that 10 years, the way I work bares no resemblance to the way we used to, but to my horror, for him, nothing seems to have changed. In fact I’d say he’s less confident than he used to be. How can this happen?
I talked to his manager about the way I choose to work now; he was impressed but declared it could “never work here”. His programers are not assertive enough to make those decisions themselves, they always waited to be told. So managers, architects and business analysts create functional and technical specifications that his programmers could convert to code. Specifications that reflected the way that they coded back when they were programmers.
So development grinds forward at a painful pace. “Improvement” isn’t a word I’ve ever heard here. “Innovate” is something they pay outsiders to do.
“Collaboration” that’s another word that seems a dirty one here. Despite everyone dutifully turning up to their desks everyday, they rarely speak, too busy reading emails and documents written by the manager across the way. Without a team there is no support, no courage to challenge this oppressive way of work. So instead they get their heads down and get on with it, while their organisation slips into irrelevance. Whilst everyone sees a problem, no one sees it as theirs.
So how can they improve? Perhaps a dose of my old friend’s humility and kindness would be a good first step. To see that it’s not somebody else’s problem but a system that was created in the name of conformity, predictability and control. And to come together and look at that system and let everyone take a lead in changing it in the name of openness, learning, creativity and growth.
Let those people creating the software, create the system of creation too.
Having work visualized is the most obvious benefit of using Kanban boards for project management. Nothing else captures so well what a team is doing , as the work is retrieved from the hidden virtual closets of our minds (or, rather, databases), and externalized on a Kanban board. Especially if this board can be seen not only on a desktop computer but on a large wall-mounted screen. The more our office environment is saturated with all kinds of visual reminders, subtly incorporated in the surroundings, Kanban board being one of such reminders, the more likely we are to keep focus on our work and to perform better.
I don’t want to keep dwelling on how great Kanban is, though. I’d rather look into some of the reasons why we at times feel that something is wrong with the electronic Kanban board. Putting it in words will help see how to tune this “digital equipment” to our particular needs.
I have soo many cards on the Kanban board.. How do I make sense of all of them?
This feeling will most likely beget companies that experience rapid growth from 10 to 20 to 50 people and beyond, and need to work with more and more cards in their Kanban boards. All is fine, until your backlog and work in progress is covered by 50-70, or 100 cards at most. Having any more cards shown on a board in a snapshot would be a no-no. The clogged board space rather hinders your work, than facilitates it. What would the solution be, then? Your Kanban board needs to be able to zoom in/out, with the ability to collapse cards in any given state, as on the screen below:
I need to visualize milestones. My Kanban board does not do that :(
This could be a real showstopper. While we appreciate the visual flow that Kanban provides, we are not working in car production, like Toyota. They didn’t have this need to pay attention to time. Assembly line process goes in circles. In software production, though, projects are time-sensitive in 99% cases. It’s quite rare, if not totally utopian, for a company to operate without looking at their watch. The clock is ticking, and if a Kanban board has no way of showing “what time is it?” for a project, this could be a huge source of discomfort. Ideally, we want our Kanban both to keep looking like a board and to convey the sense of time. Like that:
I want my Kanban board updated real-time on any screen in the world that has it open!
This is not a crazy perk. Some companies work with several distributed teams. Even teams located in one office building and in different rooms need such live updates to track their work items real-time. If you are not looking to clear a mess with some un-synced updates (hardly you are), you will want your Kanban board to show the updates like this:
I’ve covered just 3 common cases in this write-up. Any further look into the “what’s wrongs” will depend on what you need to see, to do your work, in your company.
Look into the peephole on the right, if you want to explore how 99% of all possible Kanban “what’s wrongs” can be successfully tackled in a visual project management tool.
The Three Stages of Agile AdoptionOver the past decade, I’ve witnessed common patterns of successful agile adoption and have grouped them across three stages shown below, which I call the apprentice, journeyman and mastery stages.
When speaking about agile, we're talking about the agile values and principles. How these are embodied in your day-to-day practices depends on your culture and the framework for your process. Scrum is one such popular framework, Kanban another. These frameworks are great scripts for starting agile, but over time teams change the practices and even blend them. In this article, I'll mainly use Scrum terms, but your terms may vary.
ApprenticeTeams that are newly formed and/or are new to agile aren't expected to apply agile practices very well at first. They need constant coaching as they struggle to figure out who does what and when.
Apprentice teams learn how to deliver features at a regular cadence and apply new roles such as Product Owner and ScrumMaster.
I prefer to see apprentice teams follow the practices, such as those of Scrum, “by the book”, because changes at the start of Scrum adoption are usually done to conceal problems Scrum exposes.
Effective Daily Stand-ups
One example of abandoning a practice too early is when teams skip the daily stand-up meeting because they feel an electronic tool is better for reporting task status. Reporting task status is a part of the stand-up, but it is not the primary purpose and so something is lost. The daily stand-up is meant to align a cross-discipline team to their daily priorities, revisit their commitment to their sprint goal and recommit their accountability to delivering quality features. Thinking that it's all about task reporting is a vestige of a task-assignment culture and it takes a while to change this mindset.
Forming cross-discipline teams that can commit to goals is critical to early adoption. Departmental or siloed organizations will resist the formation of cross-discipline teams. Not only do department managers fear losing control, but developers themselves will resist being teamed with those outside their own discipline. Yet, if cross-discipline teams don't form, then the weight of dependencies and the inability to deliver a demo-able game every iteration, will prevent most of the benefits found with agile.
Well formed cross-discipline teams can take more ownership of their goals, which leads to more effective problem-solving and higher productivity.
Roles, such as Product Owner and ScrumMaster, are meant to balance the need to build the right features in the right order and in the right way. The roles are separated, because they often come into conflict with one another and need to be balanced for there is a fine boundary between building features faster through improvements to productivity and building features faster by dropping quality.
Realigning existing roles with the new ones take a while to establish and even longer for the teams to understand how they are meant to function.
JourneymanWhen agile teams create a definition of done and start altering their practices to achieve it every iteration, it's a signal that they are entering the Journeyman stage. The following areas of development maturity are common with Journeyman teams.
Through close collaboration, Journeyman teams reduce handoffs of written design documents and concept art. For example, instead of a dozen storyboards for a level, a concept artist will draw half as many and spend more time working directly with the level artists and designers. In this way, all disciplines can more effectively collaborate and iterate on more emergent and higher quality levels than a one-way handoff of concept art would allow.
As cross-discipline teams iterate more, the inefficiencies of practices such as branch-and-merge and hand-testing everything are replaced by practices such as continuous integration, test servers, unit testing, etc. These practices allow more iterations on up-to-date assets and code throughout the day. The ability to iterate more frequently contributes to higher quality.
As mentioned above, faster integration requires improved testing practices, such as test servers. Additionally, Journeyman teams will increasingly integrate members of QA onto their team. This will lead to further refinements of the definition of done.
As journeyman teams improve their definition of done, agile estimation techniques can be employed to produce a more reliable forecast about the schedule, cost and scope.
MasteryMastery is a stage occupied by so-called hyper-productive teams. These teams hold themselves accountable to their results, practices and organization. For teams to enter this stage, they must have an established level of trust within the organization and be allowed to achieve higher levels of self-organization.
Sometimes, when I visit a team that has been effectively inspecting and adapting agile and Scrum practices for a while, it’s hard to say “they're doing Scrum” anymore. They completely own their work, and take much pride in it.
The goal of Scrum is to leverage the power of small, self-organizing teams to maximize the value they create. By giving teams and individuals more freedom to make decisions about their work and providing structure, coaching and mentoring, their work becomes far more focused and meaningful.
Studio culture and structure are often barriers to this “low constraint” form of self-organization. Fortunately, as more studios emerge that demonstrate the value of this approach, the acceptance and proof of it will continue to grow.
Following a set of prescribed practices isn’t the goal. The goal is continuous improvement. Markets and technologies change. Individuals change. Processes have to change as well. There are no "best practices" because the word "best" implies that there are no better.
It's Not Easy, but it's RewardingThe agile state of mind challenges our beliefs and assumption and insists that we continue to challenge them. It flat-out defies the persistent superstition that we can treat creative people with the same tools that make machinery more productive, that we can add more people or add more hours they work or write bigger planning documents, which will result in more output. People are far more complex.
It makes us coach, listen, challenge, inspire, care, respect, and collaborate in ways we were never trained to do. It's a lifetime challenge with no finish line in sight.
 These are not unlike the three stages of martial art mastery called “ShuHaRi”
 This is not inherent to Scrum teams, all new teams go through a settling phase. Google “Tuckman’s stages of group development” for more on this.
Many years ago, I was part of a task force to “standardize” project management at an organization. I suggested we gather some data to see what kinds of projects the client had.
They had short projects, where it was clear what they had to do: 1-3 week projects where 2-4 people could run with the requirements and finish them. They had some of what they called “medium-risk, medium return” projects, where a team or two of people needed anywhere from 3-9 months to work on features that were pretty well defined. But they still needed product managers to keep working with the teams. And, they had the “oh-my-goodness, bet the company” projects and programs. Sometimes, they started with a small team of 2-5 people to do a proof-of-concept for these projects/programs. Then, they staffed those projects or programs with almost everyone. (BTW, this is one of the reasons I wrote Manage It! Your Guide to Modern, Pragmatic Project Management. Because one size approach to each project does not fit all!)
The management team wanted us, the task force, to standardize on one project management approach.
In the face of the data, they relented and agreed it didn’t make sense to standardize.
It made a little sense to have some guidelines for some project governance, although I didn’t buy that. I’ve always preferred deliverable-based milestones and iterative planning. When you do that, when you see project progress in the form of demos and deliverables, you don’t need as much governance.
There are some things that might make sense for a team to standardize on—those are often called team norms. I’m all in favor of team norms. They include what “done” means. I bet you’re in favor of them, too!
But, when someone else tells you what a standard for your work has to be? How does that feel to you?
I don’t mind constraints. Many of us live with schedule constraints. We live with budget constraints. We live with release criteria. In regulated industries, we have a whole set of regulatory constraints. No problem. But how to do the work? I’m in favor of the teams deciding how to do their own work.
That’s the topic of this month’s management myth, Management Myth 28: I Can Standardize How Other People Work.
If you think you should tell other people how to do their work, ask yourself why. What problem are you trying to solve? Is there another way you could solve that problem? What outcome do you desire?
In general, it’s a really good idea for the people who have the problem to solve the problem. As long as they know it’s a problem.
How about you tell the team the outcome you desire, and you let them decide how to do their work?
Karl Scotland wrote an excellent blog post on Estimates as Sensors. In it, he extols the use of estimates to “sense capability and create feedback for yourself.” This is similar to my point in Estimation as Hypothesis.
At the end of this post, it now says “I don’t recommend using them to make promises and give guarantees to others.” Originally, this said something like “I don’t recommend using them to make promises and setting expectations of others.” I asked him what he did use for setting expectations. He had two responses. “I’d say expectations are set from understanding our capability, refined through sensing, and with a confidence range.” and changing the post to reflect his original intent.
There’s more to this business of setting expectations.
First of all, when we uses sensing estimates to understand our capability, we’re setting our own expectations. We can be pretty ignorant of those capabilities if we’re not paying attention. And, as software developers, we’re usually paying attention to myriad other details rather than our own capability. I know I do.
Years ago, I had a project lead who asked me to estimate how long it would take to fix a reported bug in some code written by a colleague who’d since moved to a different project. I looked at the bug report and made a list of the changes I would have to make. Then I estimated how long it would take to edit, compile, and verify each of those changes. I handed this annotated list to the project lead. He took one look at it and said, “You can’t do any task in 10 minutes. It will take you longer than that to checkout the code, find the place to change, and check it in again. Never estimate a programming task at under 30 minutes.” That’s when I realized that I was only estimating part of the required work, the programming part on which I was focused, not the necessary parts that enabled the programming.
I’m pretty terrible at tracking my own capacity as an individual. Not only do I tend toward a narrow focus that excludes that, but I forget to track interruptions. An interruption already gives me two things to think about at once, but tracking it would be a third. That’s a lot for one brain. I do better when I’m part of a team. The nature of team work allows me opportunities to pop up to a larger viewpoint more easily. And within a team that’s worthy of the name, it’s easy to be honest about both the capability and the uncertainty concerning it.
Even as we gain a better understanding of our own capacity, how do we set appropriate expectations for others? This is the crux of many estimation conundrums. Most developers are used to low trust relationships with those asking for estimates. They’ve been burned in the past with estimates being treated as guarantees, with estimates being treated as initial positions for negotiations, with estimates being accepted without the conditions assumed for the estimates. Who hasn’t estimated how long some task would take and then be given another task to do in the same time?
If we know how our estimates are going to be treated, we can apply “fudge factors” or “Kentucky windage” to compensate. If we know our manager is going to cut our estimate in half, we may double the number we offer. Knowing that our estimate is going to be treated as a commitment, we may pad it for contingencies. Knowing that we’re going to be subjected to interruptions, we may extend it based on interruptions in the past. How much we pad depends on whether our estimate is expected to be at the 100%, 99%, 90% 80%, or 50% confidence level.
In fact, the padding tends to go up radically the higher the expectation for the estimate. These two measurements are also related to the consequences for missing it. When someone expects an estimate at the 100% confidence level, they’re outside the realm of the natural world. There is always the possibility of something completely unpredictable, a “black swan” in Taleb’s terminology. With that unreasonable level of expectation, people often couple it with a sense that if something does go wrong, someone should be punished. There’s no allowance for things outside of someone’s control.
There is always some things we don’t know, and some of those are things we don’t know we don’t know. A friend once devised Hughes Law: “On any boat maintenance project, there will be at least three unforeseen complications, at least one of which will follow this law.” He recommended taking your estimated time for the work, tripling the number, and incrementing the unit of time measurement. That two day job becomes 6 weeks. When we have an extreme level of uncertainty, then giving any number can make us nervous.
What if we were able to set expectations beyond a simple number? What if we could say what we know and what we don’t know? What if we could give our best estimate now, and give a better one next week when we know more? Would that help?
The thing is, these questions are not about the estimates. These questions are about the relationship between the person estimating and the person using the estimate. How can we improve that relationship?
At last year’s Technology & Innovation -- the Future of Banking & Financial Services conference in Sydney, Australia, senior executives repeatedly used the following keywords (even, at times, trying to outdo each other with them):
The first keyword is easy to understand and confirms something we know, but often overlook: we need to be more “customer-aware” and listen to customers’ needs and wants, rather than assuming that we already know what these are.
Here's a good example of what it means to be customer-first: at the TUANZ (telecommunications forum) conference in New Zealand several years ago, three telcos made presentations. The first two went up to the podium and showcased their new glitzy, glamorous products, only to face a barrage of questions from the audience about their seemingly less important products and features. The third presenter took the stage with a simple message: “This is what you’ve been asking us for -- and this is how we’ve delivered it.”
You can guess which company received the most applause and enjoyed greater business opportunities. This simple message really resonated with me and has defined my approach to business ever since.Agility
The second keyword, “agility,” is more ambiguous. What do senior decision-makers really mean by agility?
It doesn’t require poetic licence to interpret agility as adopting Agile concepts -- such as the ability to work efficiently with minimal waste; delivering in shorter, faster cycles; divesting the big, overarching programs to smaller, value-focused initiatives; focusing on a collaborative, transparent culture; and being able to change and adapt swiftly to meet changing market conditions or a customer needs.
(I hope I'm right in interpreting the executives' message.)Transformation
But what about the third keyword: “transformation”? At the Technology & Innovation conference, it was disappointing that no-one questioned what this term actually means. In my experience and from discussions with customers, there are two very different interpretations for the word transformation, used in this context:
- Optimising the IT department to deliver maximum value whilst focusing on quality and throughput (the major “continuous delivery” initiative recently announced by Australian telecommunications provider, Telstra, is a good example of this)
- “Organisational transformation,” where organisations look beyond IT to fundamentally changing the very way they’re structured
As an Agile practitioner and coach, I see Agile as a set of tools and concepts we can use to deliver fantastic solutions and enhance our customers’ experience. This does not mean Agile is solely focused on the IT or engineering department: in fact, I would love to see the words “IT department” pushed to file 13 and hear more talk about the business delivery teams. After all, isn’t that why we’re here?
In most cases, when an executive is talking about transformation he or she actually means they want to optimise the manner in which IT work is flowed through their delivery systems. Hence the focus on scaling Agile, continuous delivery, and creating “Scrum teams.” There’s nothing wrong with this approach and indeed it is a necessary step along the path.
The bigger definition of transformation, however, delivers significantly greater value and has a far more wide-reaching scope. It includes bringing agility to areas such as legal, finance, HR, operations, real estate, and the executive suite.Where Are You?
To deliver the greatest value from our delivery systems we need to look at all the pieces of the puzzle. Here are some questions to ask yourself in figuring out where you fall on the transformation path:
- Do your funding regulations and approaches align with an Agile way of working?
- Do you hire managers, leaders, developers and other personnel with the personality traits to support an Agile delivery approach?
- Are your operations teams involved up-front and continuously throughout the delivery cycle, or are they the forgotten teams at the bottom of the cliff, where you push off a solution to the public and expect them to support it?
- When it comes to real estate, are your office spaces fitted out to support a transparent and collaborative culture?
- Are your executives trained to personally champion and lead an Agile approach?
- Do the people who interact with your organisation’s customers understand the streamlined delivery approach of Agile, and align their work requests, funding, support, and communications strategies with this approach? In other words, are they part of your delivery team?
Now that you've thought about these questions, where do you come out on the transformation continuum? I would hazard a guess that some of these questions were hard for you to answer: you wanted to say “Yes” but if you were totally honest, your answer would probably be a “No.” If that’s true for you, then consider this an opportunity to start a discussion around how to really transform your business and delivery activities with a well-structured and disciplined delivery approach.
We do so many things right; yet the drag of the past, fear of risk, and loss of control is a millstone around the neck of progress. You can transform into an organisation that delivers customer-first products and services, to great applause and business success; and the path to your transformation begins with agility.
This post was originally published on ItemsOnTheLeft.com.
Author Carol Dweck has completely changed the way I approach the world.
I’m a smart guy. I’m no genius but I’m pretty smart. Through most of my life, I’ve been able to get by just by being smart. For the most part it has turned out to be a pretty good strategy. I complete tasks in less time by thinking about them longer, I demonstrate industry knowledge (thus impressing my bosses) because I can hold a lot in my big fat brain. The problem is, I allowed the world around me to turn my smarts into my identity. It became my brand, and I felt a constant subconscious urge to protect that brand. As a result, I would avoid any attempt at a challenge to my intelligence. Unfamiliar things were anathema because not knowing about them made me look not smart. I avoided anything above my cognitive pay grade, and chose the activities that allowed me to shine.
Kinda limiting, don’t you think?
Enter Carol Dweck. She wrote Mindset, a book I find myself recommending in just about every conversation I have. In it, she describes me exactly. I had, as she describes in her book, a fixed mindset. Someone with a fixed mindset believes that intelligence and abilities are fixed; you’re either born with them or you’re not. A growth mindset, however, is one that believes that intelligence is not fixed and that, with enough effort and grit, anyone can be brilliant. The message isn’t new; it’s basically a very detailed version of, “Whether you think you can or you can’t, you’re right.” But what is new, as she explains in her book, is the science and evidence behind that way of thinking.
She compares John McEnroe (fixed mindset) to Michael Jordan (growth mindset). John McEnroe would blame everyone but himself when he lost a match, but Michael Jordan consistently put in the effort to become the best basketball player ever. McEnroe wouldn’t allow himself to be labeled as someone who has something to learn, he considered himself a born tennis great. Jordan, on the other hand, was always learning, always trying to make himself a better player.
Since reading the book, I’ve looked at the world in a completely different way. Instead of looking for opportunities to show off my intelligence, I’m looking for opportunities to grow my intelligence. Instead of gravitating toward subjects with which I’m already familiar, I’m entering into new and unfamiliar domains. I’m learning about sales. I joined an indoor soccer team. I’ve always considered myself rather bad at sales and just plain awful at soccer. I’m no longer embarrassed to say that I don’t know something. Instead, I’m eager to learn about it. I don’t allow failing to result in labeling myself as a failure. Instead, I learn from it.
I value learning. And there’s a lot to learn in the domain of software development. Because it’s hard.
I believe the creators of the Agile Manifesto value learning as well. They just went about expressing it in a different way. Take a look at the first sentence:
“We are uncovering better ways of developing software by doing it and helping others do it.”
Imagine, instead, if this first sentence was written like this:
“We have uncovered the best way to develop software through academic research.”
We are uncovering better ways of developing software. We’re still trying to figure this thing out. We’re still learning. Just like doctors who say they “practice” medicine because they haven’t perfected the science, I think that we’re practicing Agile because we haven’t perfected the process. And I don’t think we ever will. That’s why we always have to be learning.
By doing it and helping others do it. By digging in, failing, and learning – we’re putting our reputations on the line by experimenting with software development approaches in settings where money is at stake.
Learning is everywhere in the Agile mindset. We learn from our customers through rapid and frequent feedback. We learn from each other through regularly scheduled retrospectives. We respond to change because we learn about shifts in the market. We rework and refactor because we learn that there’s a better way to lay down code. To truly be Agile means to be in constant learning mode. To be Agile requires a growth mindset.
Have you noticed that the term “best practice” is hard to find in the Agile canon? That’s because there really are no best practices. We implement, we retrospect, we tweak. With all that tweaking, how could we ever settle on a best practice? If we’re too focused on implementing the best way, we’ll never find the better ways.
I offer an additional Agile value: Learning over Best Practices. While there is value in best practices, we value learning more. I’d like to know where you stand on this. Please drop a comment or hit me up on Twitter at @johnkrewson. Maybe I can learn something from your feedback.
You used to practice them, but then got sloppy.
Or you never really learned to practice them that well before the need to scale was pressed upon you, and now things are growing up and out too quickly to go back and shore up the details.
How do I know this?
I’m just playing the odds that your organization probably falls into that very large group that is struggling to realize the potential of Agile. And I’m considering what I observe all too frequently to be at the root of the struggle.
We all know what we have to do if we want to get in shape, right? Eat better, eat less, and exercise regularly. Simple. So why does the fitness industry rake in tens of billions of dollars annually, while the incidence of obesity and diseases related to lack of fitness keep increasing?
Want to build a financial nest egg? Save and invest more, and consume less, of course. Again, very straightforward, but current research indicates that 76% of Americans are living paycheck to paycheck. Why?
For both of the above, the answer is, more often than not a) the delusion that “the normal rules don’t apply to my situation”, and/or b) a lack of discipline.
Ineffective Agile adoptions, including enterprise-scale transformations, can be traced to these same two causes. In fact, this applies to most things that we human beings don’t follow through on.
So why am I pointing out something so obvious and so universal?
Because I don’t want you to fail.
I don’t want you to run out and buy the Agile equivalent of a Treadmaster 9000 and a “Get Rich Tomorrow” home study course, only to find yourself sick and broke a year from now.
Is your organization holding onto collaboration-killing and throughput-throttling processes, based on the rationale that your business domain or product or technology mix is more complex than that of everybody else who is practicing Agile?
Is it shaving the sharp corners off the parts of Agile that are uncomfortable, either leaving gaps or replacing what was removed with something softer and more accommodating of the status quo?
True, successful Agile enterprises are continuously inspecting and tweaking how they do things. That’s how they get better. But they are tweaking the application of the fundamentals, not the fundamentals themselves.
Even “seasoned” Agile organizations plateau, and then seek out some advanced Agile concept or technique that is guaranteed to take them to the “next level”. But there is none.
No professional sports team’s coach says, at a post-loss press conference, “Well, we were just one or two trick plays away from winning this.” No, what they actually say is, “We didn’t execute on the fundamentals, and it cost us the game.”
The secret to Agile success is that there IS no secret. Success comes through relentless improvement in the application of a few fundamental concepts and values. Your situation isn’t the rare exception.
Yes, this can be challenging, especially when the impediments that need to be addressed are rooted high-up in the enterprise. If it was easy, every organization would be wildly successful, and lots of Agile consultants I know would be running Tilt-a-Whirls at carnivals all over this great country of ours.
But that doesn’t mean it isn’t worth the effort. If you want to succeed, you don’t really have a choice.
I’m invariably surprised how often I get contacted by project management organizations, who want to guest post on my blog, or engage me in some other way to help promote their tools and techniques. Even after twenty years of Scrum in our industry, where the project manager role is noticeably missing, there is somehow a perception that a scrum master and a project manager are the same role. Or that there is still a place for project managers in an agile process. There isn’t. Here, verbatim, is a recent exchange with a tool vendor. Names have been changed to protect the misguided:
My name is John Smith and I represent a team of devs called PM Tool Makers. We build advanced project management software for people with skill and expertise—like your audience. [That’s you, dear reader]
I’m currently preparing a Slideshare presentation on Project Management with 25 - 50 quotes from top influencers in the industry. As you may know, online presentations are currently one of the biggest (and fastest) means to reach great deals of people and Slideshare is no exception here.
I’d really appreciate if you could provide us with one quote of yours that people interested in Project Management could benefit from.The presentation will be branded and you can see it below the link and you also see it in attachment
Looking forward to hearing from you - we’d love to have you included.
I appreciate being noticed, of course, but I usually get the sense that these guys are crawling the agile blogs and hitting on agilists indiscriminately. Kind of like the lonely guy at a night club who thinks maybe he’ll just get lucky tonight. Anyway, I responded:
Thanks for writing. It’s no secret that I don’t have much respect for the discipline of project management—in fact I’ve often written in opposition to it. I believe projects need to be guided, not managed, and that guidance best comes from the teams building the software and the users who use it. I find the role of project manager to be somewhat unnecessary overhead—at best a plug for a hole that people are not effectively stepping up to fill for themselves, usually due to autonomy and empowerment issues with the organizational system in which they work.
Management (of all kinds) is a twentieth century invention. Prior to that we had mentors, master craftsman, visionaries to guide us. I’d like to see a revival of that model.
So, I’m not really the best person to offer you a quote. But here’s something, anyway:
Don’t manage projects. Instead guide teams to manage their own work, and to collaborate with their users. Let go of control. Listen to the voices of the people doing the work. Embrace uncertainty. Ultimately, create an environment where your job becomes superfluous.
Probably not the kind of thing you are seeking :)
Best of luck with your presentation, and your product.
I rather liked the quote. John Smith did not.
Thank you for your quote, but necessarily—yes, is not the kind of I am seeking.
Thanks for your message and good luck!
My job, as I see it, is not to perpetuate the myth that project management is a useful discipline, but rather to challenge that old assumption. At the same time I believe I have a responsibility to socialize a different way of working to those good folk who find themselves in a dying profession. Others have different ideas.
Today is a great day to share some killer tips on how to get the best out of one’s creative potential. These tips would be of special help to digital creative individuals, that is, to anyone, who thinks for a living as they look at a screen. So, whether you are a graphic artist struggling for that elusive touch that would make a corporate identity unique, or a UX designer who wants to put together an intuitive interface, or a product owner looking to figure out what goes next in a product, or a project manager looking to facilitate a team’s performance, or a software developer crafting a piece of code, look no further. This article is your philosopher’s stone for achieving top results.
So, friends, lend me your ears. To turn on this magical power of brilliant insights, one just needs to do these three simple things day in day out.
1. Wherever possible, spend the bulk of your most productive time, preferably in the morning, when your brain is fresh, doing a research online as to how others have done this thing that you’re working on at the moment. If you’re a graphic artist, make sure you not only dig out all possible images or ideas that can be replicated, but remember to throw all those links with images at the other fellow designers in your team. Not only will this help strangle their creative edge ensure that all the industry-accepted standards are followed, but they won’t need to spend any more effort on inventing original concepts. Leave no stone unturned. You need to chase each and every clue. For strategic decisions, make the list of step-by-step routines copied from how others addressed the same challenge. You will never do anything valuable if you fail to follow the proven routines that other people have followed many times before.
2. The second magic success ingredient is to expose the drafts of your work, or to have your incentives for strategic decisions bullied discussed by as many people as one can possibly get. Facebook is an ideal space for that. Remember to be consistent in sharing the in-progress sketches or ideas with strangers, who don’t know you personally and who are completely unaware of the particular context you’re working in. They’d shoot their comments, wasting your time making their invaluable contribution to shaping up this great idea, or a graphic, or a piece of code you’re currently working on. Consistency is the key here. The more exhausted you get filtering out the rare grains of sensibility from the avalanche of clueless comments, the closer you’re to what you’re looking for. The logic here would be the same as on the picture below. One is more likely to build a snowman with plenty of snow, picking out those special unretarded pieces with care.
3. Finally, there goes the trickiest part. Once you’ve let out your finished and polished brainchild to the outer world, work to secure the right attitude to external criticism within yourself. You absolutely need to master the skill of proving your worth based on each and every comment received from your network of personal and professional contacts. The smartest way to accomplish this would be to build a model that would transform the bites of criticism to a numeric value. You’d need to set a certain plank for yourself with this model. Once this value gets below this plank, you need to work harder on the points 1) and 2).
Repeat this cycle forever, and you will sleep serenely, like a baby, enjoying the bliss of reaping harvest from all your hard work.
Em is a senior manager in Information Management. She is a certified Scaled Agile Framework Program Consultant (SPC) and an active member of the Agile community. She frequently speaks about her experiences with Scaling Agile and Agile Data Warehousing at conferences across Australia and the United States.
As mentioned in a prior post, the idea for the EDW Agile Release Train came from reading +Dean Leffingwell‘s Scaling Software Agility. A couple of months after reading the book, there was a restructure and I found myself leading the technology team that I has previously been a customer of. I was eager to pitch the idea of forming an Agile Release Train to my new team, so I arranged a series of workshops with the key leaders across the group.
From these workshops I hoped to achieve shared understanding and agreement on the shape of our future organisation. We kicked off with +Mark Richards sharing what he had learnt about Agile Release Trains from Dean’s Lean Agile Enterprise Leadership Workshop. We also provided everyone with the details of Dean’s more recent book, Agile Software Requirements. Over the remaining workshops we debated various organisational models, operating principles and approaches to getting started until we landed on a majority consensus on the way forward. With our vision agreed it was all hands on deck to get ready for our first release planning (PSI) workshop tentatively scheduled to happen in about 6 weeks.
As the day of our first release planning event grew closer, I noticed that there were some blank faces among my extended leadership team when I referred to various aspects of what we needed to do. My heart sank as I asked the team, “Who has read the book?“. A couple of hands were raised. “Who has finished the book?“. Only one hand (and yes he still works with me!). “Who doesn’t own the book?“. At least four or five hands were sheepishly raised. “OK” I said “Change of plan. We are all going to buy the book. If you cannot afford the book, let me know and I will arrange a book for you. Then we are going to read the book together. We are going to form a book club!” As Deming said, “without theory there is no learning”.
For the next 3 months I met with my extended leadership team for an hour a week. Each week one member of the team lead a discussion on a chapter or two. We would discuss the concepts covered, how they might apply to our situation and agreed on the ideas we wanted to implement. Book club was compulsory and if one team member had something more important to do then book club was rescheduled. Shared understating and agreement was paramount if we were going to be successful. Visitors to the EDW Release Train are often shocked when they hear that I called a mandatory weekly meeting to read a book. I am always quick to remind them that no one would hesitate to call a “business” meeting, so why wouldn’t we want to make time for a meeting focused on learning ways to improve our “business”.
While the “Leffingwell Book Club” (as it was fondly referred to) created the shared understanding that I was eager to achieve, there were some unexpected but positive side effects. First, more book clubs spun up. Our Scrum Masters started with Coaching Agile Teams, our Technical Leads readAgile Analytics, the Test Leads read Agile Testing and one of the feature teams chose to readLean Software Development: An Agile Toolkit. Second, the foundations of what would become our Leadership Continuous Improvement Team emerged as we created a kanban wall to track all the ideas we wanted to implement.
The third and most amazing side effect of the book club was how it enabled the formation of a team. My extended leadership team, was made up of various leaders from the 3 groups that had been merged to create my new organisation. Dean’s book gave us safe material to debate (no pun intended!). No one needed to be worried about hurting someone else’s feelings when offering an opinion on the material.
Today reading is a huge part of our learning culture. Who is reading what is a constant topic of conversation. When people visit us for “tours” we find our book club wall is one of the most photographed and talked about aspects of the EDW Agile Release Train. Some of our visitors have even been inspired to launched their own book clubs – and not just the agile folk! To quote Dr. Seuss, “The more you read, the more things you will know. The more you learn, the more places you’ll go.”For a list of books that have inspired us check out our virtual book club wall. This post first appeared on Em’s blog on October 13, 2013.