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.
When the day to travel arrived, you reset the odometer, set up the GPS and off you went. However, the job of planning wasn’t complete. There might be detours along the way. Frequent glances at the odometer or GPS might inform you that you are ahead or behind schedule. Also, the map and GPS aren’t enough. You monitor your speedometer from time-to-time and constantly look out the windshield and at the mirrors in case another driver does something unexpected.
We use all these different measures and methods to maintain a plan and respond to change for something as predictable as driving. We need similar tools for the far more complex and uncertain endeavor of making a game!
Figure 1 - Planning Onions for Driving and Games
The figure above shows “the planning onion”, which represents the different layers of planning frequency. The inner layers of the onion are the more frequent inspection tools/cycles, while the outer layers encompass tools applied less frequently.
Layers of Planning
Let’s examine the layers of planning from the inside out using the driving example for comparison with how a Scrum-developed game would plan:
- Daily - The team will meet every day in a daily Scrum to discuss the progress and issues which are affecting their Sprint goal. This includes conversations about bugs, impediments, dependencies, or merely points about the quality of the game. This is like looking out the windshield of the car during your trip.
- Sprint - The team, product owner and domain experts forecast what is possible to accomplish in the next one to three weeks. The duration of the sprint largely depends on how much certainty the team has with the work and how long the stakeholders can go without seeing something. A team will forecast and track the work in any way they want for the sprint. Some teams use hours, others days, while some teams will come up with their own units. This compares to using the speedometer in your car to measure you velocity.
- Release - The team, stakeholders, marketing and leads identify stretch goals for the game that they hope will be demonstrated in a “shippable build” at the end of the release. Product owners might alter these goals during the release as quality, cost and true velocity emerges. Forecasting and tracking during a release is usually done using metrics that size the features on the backlog (e.g. story points). This level of planning and tracking is comparable to using an odometer during your drive. The odometer gives you a more long-term view of velocity when miles are measured against larger units of time, such as hours and days.
- Project - For a cross-country drive, you’ll likely have a map and a rough idea of your progress and stops along the way. You may have a gas budget and looked online to see where major construction delays might occur on your path. If asked where you expect to be tomorrow night, you’d have an answer like “Denver”. If asked where you would be at 2:15 PM tomorrow, you might not be much more precise. Long-term project planning should be like this. It focuses on the major cost, schedule, and feature goals and identifies significant areas of risk. Similarly, long term planning will break out epics and define some constraints based on experience. An example for “online multiplayer gameplay” might be:
- Cost: 10 people for six months to implement and 20 people for six months to produce content.
- Schedule: Starting in June, finishing in 12 months.
- Risk: Online technology risks and core gameplay risks.
Just as we don’t forecast our speed down every mile of road while planning a cross-country drive, a long project shouldn’t forecast what teams will be working on every day for a year or more. Instead, as the planning horizon extends out, the metrics for planning become larger grained and less precise. There are a few reasons for this:
Reason 1: The further out our plan goes, the more uncertainty there is with the details.
This is best illustrated with the cone of uncertainty shown in Figure 2:
Figure 2 - The Cone of Uncertainty
This figure illustrates that the further we are from shipping the game, the more uncertain its cost, scope and schedule. Everyone who has shipped a game should recognize that the great concept art and ideas and plans expressed in the initial design documents usually don’t resemble the shipped game very closely. This is not a bad thing. This is the nature of creating complex games that have a subjective and emotional dimension. We simply can’t “plan away” this complexity and uncertainty. This doesn’t mean we can’t plan. It means we need to plan at a level appropriate to the level of certainty that exists.
Reason 2: Simply breaking down a long term plan into finer details won’t give us more certainty, it’ll give us less uncertainty and waste our time doing it.
This is the hardest to convince people of. The assumption is that a 300 page design document creates twice as much certainly as a 150 page design document. When I worked in the defense industry, this assumption led me to create a 40-pound specification document for an Air Force contract. The Air Force wanted so much demonstrated certainty from their contractors, that they received documents so big they couldn’t read them.
However, numerous studies have shown that not only is uncertainty not reduced equally with more planning effort but, beyond a certain point, the attempt to plan away uncertainty with more effort (documents and spreadsheets) produces forecasts with less accuracy (see Figure 3). The reason that a bigger plan creates less accuracy is due to human nature. It’s in our nature to see a big document and turn off our critical thinking, just as the Air Force did when they saw our 40-pound document. Had they read that document with a critical eye, they would have quickly found out that it was a rushed cut-and-paste job by a junior engineer. Instead, they simply weighed it and awarded us the contract.
Figure 3 - The Accuracy of Planning Based on Effort
The tools that we choose, based on where we are in the planning onion, help us stay in the ideal range of precision, which gives us the best amount of accuracy without wasting effort.
 I’ve seen some teams estimate in “NUTS”, which stand for “nebulous units of time”.
 Although I’ve seen some producers try to do this!
 Ever wonder why new fighter aircraft are years late and billions over budget?
 One of many quote is http://tinyurl.com/leasydl
The Scrum Product Owner must lead the project strategically, collaborate with customers and team on a daily basis, and manage the business value.The Scrum Product Owner takes back the accountability from the traditional project manager for delivering the right solution to the customer and end-user. This two-day CSPO course will provide you with the core […]
The Scrum Master is a leader and a change agent on a mission. Her duty is to help the Scrum Team unlock its potential to deliver more value to its stakeholders. During this intensive two-day course we will teach you how to make a development team, a project or an organisation agile and successful. This […]
This 2-day training course provides a deeper understanding of Kanban for knowledge workers. The training is therefore particularly suitable for those who: want to start with Kanban and are looking for initial support have already introduced Kanban and want to check if the implementation complies with state-of-the-art Kanban knowledge This is a certified Kanban training […]
Certified Scrum Master The Scrum Master is a leader and a change agent on a mission. Her duty is to help the Scrum Team unlock its potential to deliver more value to its stakeholders. During this intensive two-day course we will teach you how to make a development team, a project or an organisation agile […]
The Scrum Master is a leader and a change agent on a mission. Her duty is to help the Scrum Team unlock its potential to deliver more value to its stakeholders. During this intensive two-day course we will teach you how to make a development team, a project or an organisation agile and successful. This […]
Release planning is without a doubt one of the most challenging responsibilities for agile teams… at least that’s what I’ve experienced both personally and while coaching enterprises through transformations.
Most teams are working to deliver solutions where the question of “what will I get” at the end of a release can not be left open ended. Furthermore, these teams don’t have an unlimited capacity. They are working within what appears to be a constrained iron triangle, cost, time and scope are all fixed. Mike Cottmeyer’s recent blog about the agile home builder, discusses this challenge from the perspective of establishing a categorized budget.
It is an approach that I’ve seen work on several occasions. The process is pretty straight forward, not easy… but also not complex
Here’s a script that I like to use to help move teams from “this is impossible” to, “hey I think we can deliver!”Getting Started
Before determining how much of the budget should be spent on features, its important for the team to understand the goal of the eventual release. To help with this, I usually encourage the team to form of a mock press release, announcing their successful release to the world. Typically this includes key areas or attributes of the release that have made the release impactful to the reader. These are now key success areas for the releaseEstablishing your Budget Categories
Each of these key success areas start to emerge as high-level categories within the context of a releases budget that can be used to help focus initial scope conversations. From here the key stakeholders can allocate their budget across each of the category areas.
Quick sidebar, the asset that is available for budgeting is usually the delivery system’s planning velocity.Keep your Eye On the Ball (successful release, budget available)
Now that budget categories are set, the teams need to start working through their release plans and refining their needs for the “right” implementation based on the budget available. There are many methods for going about this process; but, by far my goto method starts with high-level acceptance criteria for each category, or feature area, that can be clarified through a mix of example user journeys or system interactions. The funds available to each of the categories should be brought down and further applied to each of these so that the planning team remembers to keep its eye on the ball. A successful release will need to both (1) deliver the functionality needed, and (2) live within the budget that is available.
This is key, without a focus on the budget available (cost) most teams will struggle to limit the scope of a release until its too late. Early budget constraints help to drive out scope that is not critical to the success of a release.
What do you think, what are your favorite ways to vary scope to successfully deliver on previous market commitments? For more on this topic, take a look at an earlier blog about calculating the budget, in cost, for agile teams.
As a Team Coach or Scrum Master, conflict within a team is something we often have to deal with. Over the years I have come across a number of techniques that help resolve team conflict. Regardless of the technique you decide to use, its important to understand or try to see each individuals map of […]
The post Dealing with team conflict and problem solving – Drama Triangle Model appeared first on ScrumSense.com.
With all the recent talk about agile being dead, we’ve been feeling a dark cloud hanging over us.
Could it really be that it’s time to throw in the towel on agile, to hang up the gloves? Is agile so broken, its principles so polluted? Should we just relinquish ourselves to the couch to watch "Office Space" on permanent loop?
Despite vigorous amounts of coffee and Thriller dance moves, we couldn’t seem to chase this dark cloud away. And then ...
Then it occurred to us that maybe what we really need -- what all of us really need -- is a little inspiration. We need to recharge the very values that make agile so awesome.
We considered agile energy drinks, agile bracelets, and agile ringtones; but then realized, what’s everyone’s favorite form of inspiration? Why, motivational posters, of course.
So, to celebrate this special day, the occasion of our inspiration, we thought we’d share these motivational posters with you, too. Feel free to print out your own copies and frame them for your workspace. We hope you’ll soon feel as inspired as we do!
Wie kann es sein, dass ich immer wieder aufs Neue erlebe, dass in Unternehmen keine Feedback-Kultur gefördert wird? Die Richtlinien des lösungsorientierten Feedbacks sind zwar meist auf dem Unternehmenslaufwerk zu finden, aber dort verstauben sie in ihrer virtuellen Existenz, statt real angewendet werden. Das ist wirklich schade. Feedback ist unwahrscheinlich wichtig, um das Verständnis rund um die kontinuierliche Verbesserung zu fördern. Gegenseitiges Feedback im beruflichen Kontext zu geben und zu nehmen ist elementar, um eine lernende Organisation aufzubauen.
Aus diesem Grund habe ich es mir zur Gewohnheit gemacht, (fast) nach jedem Meeting, Training bzw. Workshop das Feedback meiner Teilnehmer einzuholen und – wichtig – auch Feedback an meine Teilnehmer zu geben. Hier meine drei Lieblingsmethoden.Feedback-Tür
Einfach 4 Post-its an die Tür kleben (++, +, -, –) und die Teilnehmer bitten, beim Verlassen des Raumes einen Punkt auf das zutreffende Post-It zu zeichnen. Das geht schnell, ermöglicht Anonymität, und ist wenig disruptiv. Ich wende das häufig bei „Feedback-Neulingen“ an, obgleich die Methode eigentlich immer passt. Man kann bei dieser Feedbacktür den Schwerpunkt auch konkret auf „Return On Time Invested“ (kurz: ROTI) legen, um herauszufinden, wie viel Mehrwert der Termin den Teilnehmern gefühlt gebracht hat. (Achtung: Bei einem überwiegend negativen Resultat sollte jedoch unbedingt eine Nachbesprechung mit den Teilnehmern erfolgen.)Blitzlicht-Gewitter
Beginnend bei mir selbst, sagt jeder reihum einen Satz. Wie geht es mir jetzt nach dem Termin, wie empfand ich das Meeting, was fand ich gut, was hat mir gefehlt – all das sind Elemente, die hier erwähnt werden dürfen. Kleiner Tipp: Es hilft, einen „talking stick“ herumzureichen (Stift, Ball, Spielzeug o.ä.), um sowohl die Disziplin als auch den Fokus zu fördern. Und wer eine sehr redselige Truppe an Teilnehmern hat, kann ruhig zur Packung Streichhölzer greifen. Wer länger redet, als ein Streichholz abbrennt, der verbrennt sich wortwörtlich die Finger ;)Wie war der Termin?
Bei einer kleinen Gruppe, die sich ohnedies öfter sieht (z.B. Dev.Team), lohnt es sich, nach Abschluss des Termins die ganze Runde bzw. einzelne Personen zu fragen: Wie war der Termin? Was war gut? Was sollten wir das nächste Mal anders machen? So bekommt man Feedback und der nächste Termin kann nur noch besser werden.
Habt ihr auch das Gefühl, dass eine tatsächliche Feedbackkultur im beruflichen Kontext sehr selten zu finden ist? Wie geht ihr damit um?
- Erfolgreiche Meetings in drei Minuten
- Agile Brazil 2010 in Puerto Alegre
- 5 min on Scrum | Es gibt noch viel zu tun