The tech industry has long used conferences to share ideas, products, practices, and news. In this era of TED talks, YouTube, SlideShare, and livestreaming, it's easier than ever to be in the audience when thought leaders take the stage.
The best conference talks -- even if they’re virtual -- elicit a reaction that’s visceral: they make you think and act differently. Whether it’s a jarring statistic, or a humorous anecdote, or a charismatic speaking style, something about the best talks stays with you long after the talk has ended.
Ring a bell? That’s the kind of talk we’re after for RallyON 2015. Here are some talks from last year’s RallyON that people still talk about today.
What’s the most intractable, inefficient, and slow-moving organization you can think of? If you said the US government, you’re probably not alone. As we learned in this talk by former Assistant Secretary and CIO of the Department of Veterans Affairs, Roger Baker, implementing Agile at the VA had powerful and mind-changing consequences.
- The department’s success rate for IT programs went from 30% to 83%
- It returned $373 million to the US Treasury budget
- It deployed the Veterans Benefits Management System—a $700 million program that completely replaced a paper-based system—six months ahead of schedule
It’s rare to get a peek at how large, publicly traded enterprises do things under the hood; it’s even rarer to hear them talk about both what’s working and what’s not. So when Wendy Nagy, Program Director at Comcast, assembled a team to share the lessons learned in the company’s Agile transformation, people listened.
- What they did right: standardizing iteration length and using common user story formats in a single Rally workspace.
- What they did wrong: a “never say no” culture that resulted in too much WiP.
- What’s working: instead of delivering in silos, teams demo features to internal and external clients at the end of iterations -- earning a reputation for delivering.
You’ve probably heard or seen a conference talk that made you think twice, made you want to share it with everyone you know, or made you change how you do things. What’s the best one in your book? What would you like to hear at RallyON 2015? Submit to our Call for Content and tell us more in the comments below.Rally Software
Have you heard about the fortune cookie meme where you read your fortune cookie and then add the phrase “in bed” to the end of it? For example:
You will learn a lot today … in bed.
A dream you have will come true … in bed.
Funny ... and maybe a little immature.
Well in the business world, the same thing works for the phrase “at scale.”
Maintain quality … at scale.
Coordinate work across development teams … at scale.
All things are difficult before they are easy … at scale.
The fact is, “at scale” can mean 100 different things based on your context. Are we talking about scaling one database up to thousands of databases? Are we talking about a system working with 10 users, as opposed to 10 million? Is it one team vs. 100 teams? A recent Huffington Post article described 10 things you can do to appear smarter during meetings; tip #6 is, “Ask ‘Will this scale?’ no matter what it is.”
“At scale” can mean so many different things that it can become meaningless.
Here at Rally, “at scale” means distributing Agile techniques across locations, across departments, and across business units. It means solving the problem of coordinating the work of hundreds of teams to get the top business initiatives completed, driving value across the enterprise. Companies do this in many different ways. Some practice SAFe®, some use LESS, and others have created a blend of both or invented their own. No matter what framework these companies are using, the problem they're solving is the same. How do you deliver high-quality value to your customers in an efficient and predictable manner?
Here, we try to drink our own champagne. We continuously seek to find ways to improve, and at times we will bring in our own transformation consulting to evaluate how to take the next step in our Agile journey. We’ve done this just in the last year, and as a result we’ve solved some internal problems and substantially increased our feature velocity.
At Rally, we challenge ourselves not to hide behind the vague problem of “at scale.” We think about how we can help you deliver business value faster, whether you've got a single team or hundreds of teams, and we think about the problems we can help you solve. Are you struggling to get your first Agile team up and running? Are you trying to convince executives that an Agile transformation is the only way you can stay ahead of the market? Are you looking for a way to plan and collaborate remotely across your seven development locations? Rally can help by connecting you to world-class coaches, products, partners, and other customers.
Talk to us about the problems you face in getting business done ... at scale. We probably have a solution for you.Stephanie Tanner
A couple of years ago, the Twitter hashtag #NoEstimates appeared. Its purpose was to start a discussion about alternatives to estimations, but the idea of a project without explicit estimates is odd to most people in software development. However, if you start exploring it, you may find better sources of information to rely on.
Thanks to Hans-Peter Korn a few years back, I finally got to meet Mark McKergow, one of the founders of the Solutions Focus approach to problem solving. (OK, the point is, it’s not about problem solving, in Solutions Focus language, but until people get Solutions Focus’ view of the world, that’s the bucket to put it in). We met in London in Nov 2009 with Andy Pols and discussed Solutions Focus and Agile development.
Mark McKergow wrote up our meeting on the SOL blog line. I challenged him to change the language of their excellent approach so it doesn’t appear so ‘la la’ (my words :). I challenged myself to do the same, to see if I can get this method to appear as strong as it really is. This note is my first take on the subject.
First of all, it’s not solutions focus, because it’s not about solutions at all.
I prefer to call it the Delta method, because it’s about ignoring the solution, and only paying attention to getting a little bit further along a desired gradient.
The Solutions Focus, or as I’m prefering to refer to it, the Delta method, is about paying attention to the Things You Do that make a situation A Little Bit Better. (even though I’m writing like Winnie The Pooh).
Fig 1 illustrates:
Normal problem/solution thinking goes, “I am here, I want to be there; Why am I stuck here? How can I get there?”
Fig 2 illustrates the Delta method (ahem, Solutions Focus) thinking:
Delta thinking goes: “In what direction would I like to be? What would perfect look like? How far along am I? How on earth did I even get this far? Wow, look what’s alredy working! even though I maybe feel possibly miserable about it? How can I make a tiny little delta bit of progress along that gradient from where I am?”
The important thing with the Delta method is not to look at the “perfect” place, but only to notice what moves you a small (delta) distance from where you are.
As I wrote in a poem way back in 1987:
© (copyright) Alistair Cockburn, 1987.
A little, plus a little, plus a little, plus: a little, plus a little: plus a little, plus a little plus a little, plus a little plus a little, plus a little . is a lot.
© (copyright) Alistair Cockburn, 1987.
Postscript: Don’t worry about reaching perfection. Your notion of perfection will change as you get closer (not unlike trying to reach the speed of light). Your deltas will change likewise.
(How’d I do, Mark & Hans Peter?)
Hans Peter Korn writes:
“What’s the difference between Kaizen and Solutions Focus?”
Well, Alistair, I will start with my understanding of Kaizen:
The Kaizen philosophy is drawn from the Japanese word kai which means “continuous” and zen meaning “improvement” or “wisdom”. The Kaizen management philosophy, therefore, is defined as making “continuous improvement”—slow, incremental but constant.
The Kaizen way (in the meaning of an attitude of life, not a set of “techniques”) encourages small day-to-day yet continuous and never-ending improvement process involving everyone from managers to workers using the most basic tenet of survival: Common sense.
As opposed to the Western brand of pragmatic why-fix-it-if-it-ain’t-broke philosophy, Kaizen extends a more optimistic philosophical view: “Everything—even if it ain’t broke—can be made better!”
While kaizen (at Toyota) usually delivers small improvements, the culture of continual aligned small improvements and standardization yields large results in the form of compound productivity improvement. This philosophy differs from the “command and control” improvement programs of the mid-twentieth century. Kaizen methodology includes making changes and monitoring results, then adjusting. Large-scale pre-planning and extensive project scheduling are replaced by smaller experiments, which can be rapidly adapted as new improvements are suggested.
The five basic elements of Kaizen are:
- Personal discipline
- Improved Moral
- Quality Circles
- Suggestions for Improvement
The key principles of Kaizen are:
- Eliminate waste (& inefficiency)
- Housekeeping rules:
- Standardized Clean Up
Based on this there are some similarities with SF: (For more information about SF please have a look at: http://www.solworld.org/notes/Jumpstart_into_Solution_Focus)
- Small Actions – tiny next steps that make big differences
- Inbetween – the action is in the interaction
and in addition to this in SF there are many principles and “tools” which might be useful to “multiply” the benefits of Kaizen:
The SF-approach is based on simplicity and building on what works. Many people have attempted to sum up the subtleties of SF. Some descriptions which come close to capturing the flavour include:
- Finding what works and doing more of it
- Putting positive difference to work
- Radical simplicity
Mark’s book The Solutions Focus (co-authored with Paul Z Jackson) describes the approach in terms of six SIMPLE principles and six solutions tools. The SIMPLE principles are:
- Solutions – not problems
- Inbetween – the action is in the interaction
- Make use of what’s there – not what isn’t
- Possibilities – from the past, present and future
- Language – simply said
- Every case is different – beware ill-fitting theory
The six solutions tools are:
- Platform – where are we starting from?
- Future Perfect – suppose the problem went away overnight – what would happen instead?
- Scaling – where are we now?
- Counters – whatever helps us forward
- Affirm – what’s already going well?
- Small Actions – tiny next steps that make big differences
And – in my understanding of Kaizen – there are some important differences between SF and Kaizen:
SF does not encourage for a “never-ending improvement process”. In SF we ask: “Is it good enough now?” and we don’t invest a lot of energy to “come from an 8 to 9” (on a scale from 0 to 10) if we think that the “8” will be good enough now. This will give us the chance to consolidate and appreciate our success instead of continously craving more and more.
SF is a very pragmatic way focusing on “observable facts and changes” and on those “tasks” which can be really done by a person – and not on humans as if they are driven from the inside by some kind of mentalistic (or even molecular) framework, or from the outside by systems or social forces. So, “abstract things” like “Improved Moral” or the “Kaizen Housekeeping rules” (Tidiness, .... , Discipline) for me seems to be on the level of such “mentalistic frameworks”.
Attention: In SF we do not deny or reject them. We simply do not actively address internal mechanism which needs to be found and followed or changed like:
- Personality Traits
- Mental Maps
or external mechanism which needs to be found or followed or changed like
- Family structures
- Power structures
- Cultural norms
People working solution focused can and do change their lives and leave all manner of problems, diagnoses and other ailments behind them without any use of, reference to or mapping of these internal or external ‘things’. Indeed, even problems declared by persons (e.g. co-workers or team members) in such terms can be handled quite satisfactorily by using and building everyday descriptions of their problems.
This “Inbetween – neither inside nor outside” (see http://www.sfwork.com/jsp/index.jsp?lnk=6d8) for me is one of the most important “specifics” of SF. And – for me – this does not stand in conflict with the “Japanese Tradition” (which is the platform of Kaizen):
I am learning “Iaidō” (http://en.wikipedia.org/wiki/Iaid%C5%8D) in a group of about 4 to 6 persons since many years – and we all still are learners, doing “only” such simple (or mostly much simpler) “katas”: http://www.youtube.com/watch?v=MIHwUrQ7x9A
And our learning is a permanent step by step improvement to reach more of Tidiness, Orderliness, Cleanliness, Standardized Movements, Discipline. BUT: The goal is NOT the “perfect tidiness” or “perfect discipline” .... the goal is to “observe ourself”: How do I recognize in my body, that a stroke is done more clear? What is helpful for me to do a clear and energetic stroke? How can I manage it to do a clear and energetic stroke with a slow movement? How can I do it fast – keeping the clearness? So, for me, Tidiness, Orderliness, Cleanliness, Standardized Movements, Discipline are means to enable such self-observations concerning the own body. So, this way is a way of mediation. And after about two hours of such work I feel much more distressed ….
Maybe Kaizen also is much more “a meditative step by step way towards wisdom” then a “method” to produce better Toyotas….
I wish you all a happy and distressed 2010!
Dr. Hans-Peter Korn
www.korn.ch: kreatives Training, Mentoring & Coaching
für agiles Management, Leadership und Teamwork
Turnweg 13 CH 5507 Mellingen SWITZERLAND
Phone: +41 56 491 3341 Mobile: +41 79 461 3379
Fax: +41 86079 461 3379 Skype: hans-peter.korn
Thanks, Hans Peter and Mark (see his comment below).
Based on your comment, Mark, I’m trying again with this double delta image (from Solutions Focus double delta view.png):
It still misses out on the specific techniques, the “action is in the interaction” part, and the “don’t think you know” aspects, but captures the “celebrate how far you already got part” maybe.
Keep comments coming and I’ll keep trying over here.
thanks – Alistair
Continuous improvement may be a fundamental tenet of Agile and Lean disciplines, but making real change in organizations is hard. If you’ve ever read a book, seen a talk, or had a conversation that changed your thinking or behavior, then you know that meaningful change often starts with someone else’s experience and advice. That’s why we’re inviting you to share yours as a RallyON 2015 speaker.
RallyON (happening June 15–17 in Phoenix, Arizona) is our annual industry conference where innovative organizations come to learn, lead, and grow. RallyON shares the best thinking, strategies, and practices to help leaders keep pace with the new speed of business and build organizations that are fast, Lean, and adaptable.RallyON 2015 Content Submission Guidelines
Be part of the RallyON 2015 agenda by nominating a speaker, proposing a session you’ll present, or suggesting a topic you’d like to see. Here’s what we’re looking for this year:
- Use cases explaining how you’re building agility across your entire organization
- Best practices, frameworks, and cutting-edge trends in Agile or Lean methods
- Success stories around the business impact of agility
- Interactive, hands-on learning experiences that drive mindset or behavioral change
Your audience will be broad, diverse, and leading-edge. This year we expect the conference to attract more than 500 attendees—from developers to product managers to executives —representing companies in healthcare, IT, manufacturing, banking, media, and government.
How are you building a faster, smarter, better organization? Share your ideas with us at RallyON 2015. Submit now to our Call for Content.Rally Software
When it comes to transitioning to agile, if a team only goes off what it's heard from other teams and doesn't take a class or read any books about the process, misconceptions can abound. And that leads to problems. Read on to have three common agile myths debunked and to learn why agile is a cultural change, not just a project management framework.
This blog is part of a series on “Agile Trojan Horses – Covert Appetizers for Agile Discovery.” This series is intended to help spark conversations that restore focus on agile fundamentals, whet the appetite to discover more about agile, and help apply agile in day-to-day decision-making.
One of the elements that I love about Agile and Scrum is the focus on humility, reflection and continuous inspection and adaptation. One of my favorite Agile Principles is #12…
At regular intervals,
the team reflects on how to become more effective,
then tunes and adjusts its behavior accordingly.
One of my favorite Scrum events is the retrospective. As the Scrum Guide says…
The sprint retrospective is an opportunity for the Scrum team to inspect itself and create a plan for improvements to be enacted during the next sprint…
…The purpose of the sprint retrospective is to:
– Inspect how the last sprint went with regards to people, relationships, rocess, and tools;
– Identify and order the major items that went well and potential improvements; and,
– Create a plan for implementing improvements to the way the Scrum team does its work.
Some common impediments prevent teams from applying the agile principle of regular reflection and from having effective Scrum tetrospectives.
– LACK OF ATTENDANCE – Team members not showing up to the retrospective.
- LACK OF PARTICIPATION – Not hearing anything at the event besides the sound of crickets – team members showing up, but not sharing anything.
- LACK OF TRANSPARENCY & INSPECTION – Meaningless conversations – no transparency and no inspection. Nothing other than whining, finger-pointing and complaints.
– LACK OF ADAPTATION – Meaningful conversations – healthy transparency and inspection but no meaningful adaptation. No follow-up actions to make things better.
Besides creating safety, one of the most important elements needed for a team to have meaningful inspection and adaptation is an ice-breaker. For many team members new to agile, the act of reflecting on the team in a safe setting, is awkward and unfamiliar.
I usually begin by putting up some flip charts with the questions…
1. What worked well?
2. What could have worked better?
3. What actions will we take in the coming sprint to make it more effective?
I add a couple of additional questions…
4. What was the most valuable knowledge we gained in this sprint?
5. What contributions would we like to acknowledge in this sprint?
In most cases, with a few nudges here or there, the team starts opening up and we have a meaningful conversation. However if the team is still not talking, you could try this approach…
In this approach, we put up a bunch of assertions in front of the team and ask them to share their responses to the statement. These approaches fall into five major categories that also help raise the team’s awareness of key elements relevant to agility…
For each assertion, ask the team to respond by choosing one of four categories…
– HUH…? - We are unaware of or unclear about what this means.
– HEALTHY – Our team is healthy in this area. No adaptation needed.
– NEEDS SOME ADAPTATION – Our team could use some adaptation here.
– BLOCKED! NEEDS URGENT ADAPTATION- Our team needs urgent adaptation here.
If the team is co-located, you could create a grid on flip charts and the team could put up colored posts.
Encourage each team member to also jot down why they chose a particular post-it, maybe with an example, if they can. If not, it is completely OK, they can just put up a blank post-it.
If the team has specific ideas on how they might adapt the next sprint to be more effective, they can jot them down on a post-it and put it up in the last column.
The grid might look something like this…
If the team is distributed, you could send them an online survey and have them respond either before the retrospective event or during the initial portion of the event.
You might try jotting down your responses as you read this blog as well, before you take this idea to the team. Now that we have set the stage, let’s start reviewing the assertions…
We begin with a section adapted from the Agile Manifesto. Reflect on how aware your team is about the Manifesto and how effective you all feel you were in applying it to your work. time-box this section, and review feedback as a group.
The next section encourages reflection on the Agile Principles. Ask the team to consider each principle and share their thoughts on how effectively you all applied them. Discuss as a group.
Let’s start reflecting on one of the frameworks under the agile umbrella – Scrum. At a high level, the Scrum framework has three core objectives. As a team, reflect on whether the processes you used helped accomplish these objectives.
Scrum is not just about rituals or “what” we do as a team. The heart of scrum are the core Scrum Values that define “how” we work together as a team. Pull up the Five Scrum Values and allow the team to share their thoughts on the team culture and how close it was to being true to the Scrum Values. Discuss as a group.
As described in the Scrum Guide, Scrum is based on the three pillars of empirical process control. Ask the team to share their thoughts on how effectively the team applied empiricism in their work. Discuss as a group.
The Scrum Guide clearly lays out the accountability for each role in the framework. Ask the team to reflect on how effectively each role or group delivered their accountability. Discuss as a group…
The Scrum Guide clearly lays out the purpose and desired outcomes for each of the five events in the framework. Ask the team to reflect on how effective they thought each event was. Discuss as a group…
Mary and Tom Poppendiek have done some amazing work how the lean principles from manufacturing offer a better approach to software development. These principles are available on their website – http://www.poppendieck.com/ and I have taken the liberty to adapt them for our approach.
By now, hopefully, the silence and crickets at the beginning of the retrospective have been replaced by meaningful conversations about how the team can inspect and adapt its work.
Hopefully, these conversations have dispelled some common myths about what agile is and is not and acted as an appetizer for the team to explore some more about agile software delivery.
Before you end the session, ask the team to pair up and pick up at least one action item to make a thin slice or process improvement in the next sprint. Without adaptation, the transparency and inspection of a retrospective are meaningless. If there are too many options to choose from, use dot-voting to help rank the options and pick the ones that fit the capacity constraints of the team.
Try out this approach even if you begin with baby steps by reflecting as an individual.
Either way, please share your thoughts. If you like, you can use this Excel spreadsheet as a starting point.
Either way, please share your thoughts. Keep calm, and Scrum on!
I have an offer you can’t refuse…
You don’t have to be afraid, just because I am Sicilian.
I am talking about Product Development here, not “garbage collection”.
I know it frustrates you that all this Agile stuff talks about uncertainty and fluffy stuff. I have a secret for you, however. It’s one of the most overlooked aspects of Agile. I will even let you in on this secret for absolutely FREE.
Here it goes…
In Scrum, there are fixed timeboxes or iterations we call Sprints. You probably knew that. However, what you probably didn’t realize is that if your Scrum Teams establish fanatical discipline and rigor around only releasing things that are in line with their strong and comprehensive Definition of Done every Sprint, you will have…
FIXED DELIVERY DATES!!!
What will undermine this is if they compromise on the various criteria in the DoD, effectively cutting corners and introducing risk into the product. Also, if they extend the Sprints, change the duration repeatedly, or have nonsensical practices like magical mystery Sprints where hardening, innovation, and planning suddenly take place then all bets are off in terms of having…
FIXED DELIVERY DATES!!!
So, let the Scrum Teams be responsible and empowered to make the critical decisions that no one else can truly and effectively make. They will make the product sound in accordance with changing customer needs and technological advancements by baking quality in, integrating along the way, practicing emergent design, improving by coming up with new ideas, and doing smaller increments of ongoing planning, as Scrum intended. The result will be…
FIXED DELIVERY DATES!!!
Now, we all know that a Development Team in Scrum is supposed to be 5-9 (7±2) people, right? If we use a blended rate of, say, $100k to represent the average salary for team members (including consultants), then we know for certain that a Development Team will cost $500-900k / year. Voila! We have…
Now, we can figure out what a Sprint costs by doing simple division. Let’s say a Sprint is two weeks. That gives us ~$19,000-$35,000 / Sprint depending on the Development Team size. Further, let’s assume our releases are every 3 Sprints (6 weeks). Now we know that a release costs us ~$57,000-105,000. That’s a beautiful thing. That’s…
You can’t ask for more!!
No, I mean literally, you can NOT ask for more; like Fixed Scope, for instance. In order to get fixed costs and fixed delivery dates in Scrum, the trade-off here is that the Scope is flexible. This is good, don’t freak out.
Having flexible scope ensures that we are able to roll with the punches and change as customer needs change, technology changes, and most importantly, business priorities change. To help us with this, we want the Sprints to be as short as possible. If we have one week Sprints, then we can formulate smaller increments in planning and ultimately have very granular refinements in our strategy rather than very drastic course corrections which are costly.
We still have higher level elements of planning that map to overall strategy: Vision, Roadmap, Release level planning, and insisting upon a Sprint Goal for every Sprint. This helps to keep us on target and focused with our longer term strategy.
So, not having fixed scope is a good thing. We could still have releases that are structured around fixed scope instead of fixed delivery dates. But it’s simply not realistic or REAL WORLD to expect to have more than one element fixed, one element firm, and one element flexible from among Scope, Cost, and Time. Those who demand to have all three fixed (so-called “firm fixed price”) are best served in taking this up by seeking an audience with OZ in the Emerald City, since they are indeed in fantasy land…
So, there it is:
FIXED DELIVERY DATES and FIXED COSTS
Peace and blessings-
Many teams think they're agile. They might work in iterations and have a ranked backlog, but they don’t see the value they could be seeing. Usually that means they have a number of false impressions about agile. Read on to have three common misconceptions debunked and to learn what you need to do to make your agile transition successful.