The Rules of Scrum: Your Product Owner refines the Product Backlog so it is ready for each Sprint Planning Meeting
The Product Owner is responsible for maintaining the Product Backlog. This includes its ordering in terms of value and effort, its clarity, and identification of what acceptance criteria apply to each Product Backlog Item. It is also very important for the Product Backlog to be ready for each Sprint Planning Meeting so that the team can select the Items for the current Sprint and break those down into tasks. If this is done, the team is able to create an effective Sprint Backlog where it can volunteer for tasks and achieve quick wins each day. If not, the team will likely take on the work of refining the Product Backlog during the Sprint Planning Meeting which is wasteful and not focused. Having a ready Product Backlog helps the team focus during its meetings and ask relevant questions to the Product Owner.
To learn more about Sprint Planning Meetings, visit the Scrum Team Assessment.
Partnership & Possibilities: A Podcast on Leadership in Organizations
EPISODE 6: COMPETITION
“There are people who fundamentally believe that competition is the way to get the best out of people, and there are people who fundamentally believe that the spirit of collaboration is the way you that you get the best out of people.”
Running time 30:20
What are your experiences with staff ranking or other policies and processes in your organization that you feel have helped you perform better or have gotten in the way of performing better? Have you seen or experienced real significant differences in policies and processes between private industries or government, schools and other such organizations?
Leave a comment on this blog or email us at email@example.com
[Intro] The pros and cons of staff rankings.
[02:36] The impact of the bell curve on employees.
[08:03] Real world example – Ken Blanchard.
[12:10] Applying business policies and processes to public institutions. Is it effective?
[15:44] Competition tends to be part of the American cultural fabric.
[18:29] Different levels of competition – from healthy competition to unhealthy competition.
[22:05] Consequences of competition.
[23:12] Introducing change that impacts only a certain group vs. starting at the top.
[24:40] How do you positively and effectively help people do good work?
[27:09] Take time to assess before making big changes.
Agile and Beyond: the words paint an image of a dark, star-lit sky. The starship Agile floats through the air toward some distant, efficient, high-performing process improvement.
Excuse the attempt at a dreamy, poetic intro; I’ve got Valentine’s Day on the brain.
Good news; this thinking need not be conceptual dreaming. Agile and Beyond, coming to Detroit next week, brings a place and platform for healthy discussions and dialogue around agile software development’s past, its present, its future.
Stop by and visit us at Agile and Beyond to learn what you need to know about managing your company’s agile processes with an agile project management tool, or continue to evolve or adapt your understanding and execution of agile. We are the first booth on the left when entering the sponsor area.
When you are not visiting our booth, check out the great slate of sessions available.
From reading the titles and abstracts, these are my favorites:
Stop Thinking and Start Doing: Action is everything, right? In this presentation, Daniel Davis will explore how we can use agile to put noble goals in place for you and your team. This will be personal development at its finest.
The Power of Promiscuous Pairing: In this provocatively titled talk, Thomas Piggott and Carol Treat Morton will showcase how pairing can yield tremendous benefits even beyond development. Who wouldn’t want to attend a talk that helps your team eliminate ‘towers of knowledge?’
Removing the UX Roadblock: Anyone who has been on an agile team with UX talent knows the struggles. A developer’s work styles, patterns, and pacing may be completely different than a UX designer’s, yet the designer’s contributions and output are pivotal to producing software. Stop thinking of the UX team as a roadblock; instead visualize them as a high-performing team member capable of greatness.
We are just scratching the surface here with the number of awesome presentations and workshops on the schedule.
Thanks, Agile and Beyond for putting together another outstanding event. We look forward to meeting the agile software development community of the greater Detroit area.
BTW: If you have time after the conference, visit one of the great Middle Eastern restaurants that call Detroit home. You won’t be disappointed.
Community Marketing Manager
Em Campbell-Pretty, a SAFe SPC and scaled agile blogger in Australia, just pointed me to an article she wrote which has just been published in the Cutter It Journal. In the issueDoes Agile=Better DW/BI, she describes how they are applying SAFe to a significant Data Warehousing program. In the article, she focuses more on the values and principles behind SAFe, rather than the practices themselves, which is always refreshing. She also describes some of the challenges unique to data warehousing, though I’m pretty sure many of you will say “we don’t do data warehousing, but we have that problem here too!”
But in fact, the entire issue is devoted to Agile in Data Warehousing and Business Intelligence, so if that’s your game, there are 6 other helpful articles there as well, including one by Scott Ambler highlighting how Disciplined Agile Delivery applies in that context.
The article is free and you can find it here:
Affectiva, a startup, is announcing the launch of its mobile software development kit (SDK) for tracking emotions.
"The company says it can analyze a user’s emotions by tracking their facial expressions, and it uses that technology to measure the effectiveness of ads. With the new SDK, mobile developers will be able to add these capabilities to their apps as well." -- TechCrunch Anthony Ha
"This means Affectiva’s technology could be embedded into consumer products — a spokesperson suggested via email that the possibilities include healthcare, education, and gaming apps." -- TechCrunch Anthony Ha
See -- TechCrunch Anthony Ha article
How could we use this tech (SDK) to nurture better teams? Reinforce positive sharing and interaction behaviors for a group of people (geeks) that love to interact with the confuser (mobile or desktop) but may be on the light-gray end of the autism spectrum?
The Product Owner is responsible for ensuring that the Product Backlog Items reflect and contribute to the vision of the product being built by the Scrum Team. Therefore, the Product Owner needs the authority to reject any suggestions for features, functionality or fit and finish that do not move the product towards that vision. This authority must be based on both the depth of knowledge of the Product Owner as well as formal responsibility granted by the organization. A Product Owner that does not have this authority to veto may nevertheless be able to accomplish the same thing by putting any unwelcome ideas at the very end of the Product Backlog based on authority to order the Product Backlog. The lack of this authority to veto can lead to a product with no integrity of vision, an erosion of the Product Owner’s authority to order the Product Backlog, and ultimately an erosion of the critical separation of powers between the Product Owner and the rest of the Scrum Team (the Product Owner with authority over “what to build” and the rest of the team with authority over “how to build it”).
To learn more about Product Owners, visit the Scrum Team Assessment.
Cost of delay part 1 was about not shipping on time. Cost of delay part 2 was due to multitasking. Cost of delay part 3 was due to indecision. This part is the cost of delay due to technical debt.
One of the big problems in backlog management is ranking technical debt stories. It’s even more of a problem when it’s time to rank technical debt projects. You think product owners have feature-itis problems? Try having them rank technical debt projects. Almost impossible.
But if you really want the value from your project portfolio, you will look at your impediments. And, if you are like many of my clients, you have technical debt: a build system that isn’t sufficiently automated, insufficient automated system tests, too many system-level defects, who knows what else.
If you addressed the build system, and maybe some of the system tests, if you created a timeboxed technical debt project, you could save time on all of the other projects in this code base. All of them.
Imagine this scenario: you have a 2000-person Engineering organization. It takes you 3 weeks (yes, 21 calendar days) to create a real build that you know works. You currently can release every 12-18 months. You want to release every 3-6 months, because you have to respond to market competitors. In order to do that, you have to fix the build system. But you have a list of possible features, an arm and a leg long. What do you do?
This client first tried to do more features. They tried to do features in iterations. Oh, they tried.
By the time they called me, they were desperate. I did an assessment. I asked them if they knew how much the build system cost them. They had a group of 12 people who “supported” the build system. It took at least 10 days, but closer and closer to 20-25 days to get a working build. They tried to estimate the cost of the build in just this group of people: 12 people time 21 days. They did not account for the cost of delay in their projects.
I showed them the back of the napkin calculation in part 1, and asked, “How many releases have you postponed for at least a month, due to the build system?” They had an answer, which was in the double digits. They had sales in the millions for the maximum revenue. But they still had a sticking point.
If they funded this project, they would have no builds for four weeks. None. Nada. Zilch. And, their best people (whatever that means) would be on the build project for four weeks.
So, no architecture development, no design, no working on anything by the best people on anything other than the build system. This company was convinced that stopping Engineering for a month was a radical step.
Does it matter how long your iterations are, if you can’t build during the iterations and get feedback?
They finally did fund this project, after about six months of hobbling along.
After four weeks of intense work by 16 of their smartest people, they had an automated build system that anyone in Engineering could use. It still took 2 days to build. But that was heaven for everyone. They continued the build system work for another month, in parallel with regular Engineering work to reduce build system time.
After all the build system work, Engineering was able to change. They were able to transition to agile. Now, Engineering could make progress on their feature list, and release when it made sense for their business.
What was the payback for the build system work? Almost immediate, Engineering staff said. When I asked one of the VPs, he estimated, off the record, that they had lost more than the “millions” of dollars of revenue because they did not have the features needed at the time the market demanded. All because of the build system.
People didn’t plan for things to get this way. They got that way a little at a time, and because no one wanted to fund work on the build system.
This is a dramatic story due to technical debt. I bet you have a story just like this one.
The cost of delay due to technical debt is real. If you never look at your technical debt and see where it impedes you, you are not looking at the value of your entire project portfolio.
If you eliminated a technical debt impediment, would that change one of your costs of delay?
No, I don’t love them for acting like police and filing reports if they spot a deviation from some “standard certified” rules in the development process. I wonder if it makes sense at all to monitor software engineering processes for compliance to abstract guidelines written by someone who’s never seen how your company actually works?
No, I don’t love them for meticulously clicking through screens in the UI-heavy cases, even though this job does deserve to be admired. Also, I don’t love them for following established testing practices without ever having a thought of questioning or tweaking them.
No, I don’t even love them for writing automated test scripts; it’s because some people view this skill as the only upper sky limit for QA’s. Neither do I love them for checking that a certain functionality in the product is implemented exactly as in the specs.
My point is that with all the above scenarios QA’s are supposed to function rather as cogs in a machine, and not as thinking individuals who have a lot more in store than the narrow-minded ability to follow rules and guidelines. It depends on an organization, of course, because in some companies QA’s are regarded only as human-shaped tools.
What is it that I love our QA folks for, then? It’s their ability to see the big picture and contribute to the quality of the product on all levels. I also love them because they keep a reasonable calm stance to bugs and glitches in software and UI. Some QA’s take it personally if the count of WTFs per minute is overriding all possible limits.
I love our QA’s for being curious people who go beyond the “human tool” thinking which seems to be prevailing in the industry, unfortunately. A professional QA person is someone with the analytical and critical mind, who reaches deeper into the background of the job at hand. It’s not only about writing automated tests, or test-driven development. The QA’s big picture embraces anything that has to do with how product appears to users. A truly competent QA will question irrational practices, bring this to everyone’s attention, and suggest ways to do things better. This sounds like a mix of internal auditor and external agile coach, and not everyone will have it, but if a company manages to raise such people in-house, the benefits are obvious.
Our QAs have this thoughtful mindset in place, and some of them have re-invented themselves outside the QA domain. A web operations/automation engineer, a product specialist, a feature owner, and there’s at least one ex-QA among those guys who overhauled our technical support and introduced the high service standards that our customers seem to appreciate.
The well-rounded QA’s are precious in almost any activity of a softdev company. They start from the bottom up and literally click their way through to the bigger picture. QA’s excel at noticing the flaws that others might miss, and this combination of inherent responsibility + attention to detail +analytical mindset makes them appear both as excellent problem finders and problem solvers.
Today I had the dubious pleasure of attending a traditional training course. You know the type: Trainer stands at the front, his laptop and projector setup. The training is focussed on showing you how to do something in a piece of software. I could be cranky, I could be bored, I could tweet about how bad it is (okay I did that), but I also decided to observe and try to notice why the training was so awful, and maybe what I could learn from it as tips to help myself and others not fall into the same traps.
Here are my 6 tips to make sure your training doesn’t suckTelling is not teaching
Stating facts that you know is not the same as teaching. It can probably be called lecturing – but don’t let the fact that it’s done at universities confuse you with the idea that it helps you learn. People have a different mental model than you. You need to help them fit the new knowledge into their mental model not just tell them yours. There are many techniques to do this, far more than can fit into this post, so do some research. If you are talking more than 75% of the time, chances are you are just lecturing not teaching.Encourage questions
Let learners know you are there to help them learn and understand. This takes more than just saying feel free to ask any questions. Those of you who know me, know that I’m not the shy type:) I quite enjoy heckling in talks and training sessions. I’m usually comfortable asking anyone anything if I don’t understand. For the first time today I felt myself holding back from asking questions, hoping I’d just figure it out for myself. The trainer was quite happy for people to ask questions, but for some questions he would say “LISTEN to me” and then repeat exactly what he had just said, which didn’t really answer the question. Make sure you understand what people don’t understand, and then use different language or a different explanation.Add references on the go
I know I’m guilty of this one, because I know we have a flip chart at the end of a session with links etc. But I noticed today how annoying it is when someone says I’ll give you a link or reference for that later. By the time you get the reference you forgot why you wanted it. I’ve seen this done very successfully by having a resource sheet up on a wall and having the trainer add things as they come up. That way you can note down the ones you care about, in your notes about the topic you care about.Keep people engaged
I spent much of today’s training doing something else (tweeting, starting this blog post, checking email etc). Mostly because the trainer was helping one person with a problem and hadn’t given the rest of us anything to do. As a result I got bored and context switched. This was made even worse by the fact that I had my laptop in front of me so literally had the whole internet to distract me. Sharon Bowman talks about ‘Sponge Activities’ which soak up time when you need to help individuals. Give the rest of the group a task to do that will help their understanding and engagement while you are busy. Make sure you check for signs that people have moved on to something else, and give your attention back to the group.Use your time wisely
Most people’s time is their most valuable asset, don’t waste it. Try not to spend your time explaining something that people could understand just as well by reading it. For example how to browse to a website on your computer (maybe unless you are teaching Internet to grannies). If you are doing practical software based training, explain the workflow and concepts without the software, then give people a task to do themselves, and let them ask for help if they get stuck. Spending 20 minutes filling in a form with 12 cells as a group is unnecessary and annoying to just about everyone.Know your audience
At the start of any training session find out about the experience of the people in the room. This will help you know if you can use industry buzzwords or not. If you need more or less explanation on particular items. If you should spend more time on basic or advanced topics. If you have both ends of the spectrum, use it to your advantage. Pair experts with novices and get the experts to help the novices, both end up learning from the experience. Also make sure people know what you will cover at least roughly. There is nothing worse than someone realising 2 hours into a training session that you aren’t going to cover the one thing they actually care about, and perhaps they shouldn’t have come at all.
Der Ursprung allen Konfliktes zwischen mir und meinen Mitmenschen ist, dass ich nicht sage, was ich meine, und dass ich nicht tue, was ich sage. Martin Buber
Eine wichtige Aufgabe von Menschen in Führungspositionen ist der Umgang mit Konflikten in ihrem Verantwortungsbereich, gerade auch in Veränderungsprozessen. Führung, als zentrale Ordnungs- und Strukturfunktion in sozialen Systemen, muss zum Umgang mit Konflikten bereit sein und Konfliktmanagement als eine ihrer Aufgaben sehen, da Konflikte in ihrer Dynamik fast immer Auswirkungen auf Leistung, Aufgabenbewältigung und das Klima im Team haben. Gerade Teams mit Selbstorganisationsauftrag sind nicht frei von Konfliktkonstellationen. Ein Konflikt ist das Aufeinanderprallen von (scheinbar) nicht zu vereinbarenden Wünschen, Zielen, Erwartungen, Interessen, Werten Ideen etc. mit einem hohen emotionalen Anteil und einer starken Handlungsdynamik mit der Tendenz zu Lösung, Eskalation oder Verhärtung.
Üblicherweise wird die Aufgabe von Führung im Konfliktmanagement, also im Bearbeiten aktueller, eskalierter Konflikte gesehen. Diese Sicht greift allerdings meines Erachtens deutlich zu kurz, um der Bedeutung dieses Themas gerecht zu werden. Methaphorisch ausgedrückt: „Ist das Kind in den Brunnen gefallen, wird es manchmal ziemlich eng, um es zu retten. Andererseits, geht das Kind nie zum Brunnen, kann es evtl. verdursten.“ Also was tun?
Es gibt vier zentrale Handlungsfelder, die aus der Führungsperspektive im Umgang mit dem Phänomen Konflikt je nach Lage der Dinge beachtet und bearbeitet werden müssen.
Prophylaxe heißt aus der Führungsperspektive, vorbeugende Strukturen zu schaffen, die dabei helfen, Interaktionen so weit als möglich konfliktarm zu gestalten. Dazu gehören definierte Erwartungen aneinander, Werte, Regeln, Normen, effektive Prozesse, aber auch teamfördernde Maßnahmen wie Teamentwicklung, Schulung etc. So kann z.B. in einer Retrospektive das Thema Konflikt gezielt angesprochen und bearbeitet werden. Welche Vorstellungen habe die einzelnen Teammitglieder, wenn es zu Konflikten käme, und wie wünschen sie sich, dass damit im Ernstfall umgegangen wird?
Früherkennung. Die genaue Wahrnehmung kritischer sozialer Prozesse im Umfeld ist besonders wichtig. Im Kontakt und im Gespräch mit den Mitarbeitern, Kollegen, dem eigenen Chef, können Konfliktsignale wahrgenommen und eingeordnet werden. Sich mit diesen direkten oder indirekten Signalen konfliktträchtiger Situationen, z.B. bei Besprechungen aller Art, auseinanderzusetzen, hilft bei der Früherkennung. Führungskräften sollte bewusst sein, wie der eigene Bezug zu diesem Thema ist. Bin ich eher „konflktscheu“, tendiere ich evtl. dazu, unbewusst Signale zu übersehen/überhören und setze gerne die rosarote Brille auf? Konflikte generieren Emotionen aller Art, das gehört dazu, ist beherrschbar und oft heilsam. Angst vor Gefühlen, der Versuch, immer alles rein auf der Sachebene regeln zu wollen, hindert daran, sich Konflikten „echt“ zu stellen. Ganz gleich, ob selbst beteiligt oder als Führungskraft in „neutraler Posisition“, wichtig ist es, Verantwortung für Konfliktsituationen zu übernehmehn. Das gehört zur Fühungsaufgabe.
Bearbeitung. Wenn eine Konfliktsituation bereits akut geworden ist, hat die Führung die Aufgabe, einzugreifen und konkrete Maßnahmen für eine Konfliktklärung anzustoßen. Führungskräfte können je nach Eskalationsstufe selbst agieren oder externe Konfliktmanager engagieren. Wichtig, und nicht immer ganz einfach, ist dabei, den richtigen Zeitpunkt und das funktionalste Vorgehen zu erwischen. Bin ich zu früh, „leugnen“ die Mitarbeiter den Konflikt oder unterschätzen die Eskalationsdynamik. Bin ich zu spät, hilft oft nur noch Machteinsatz. Und das hinterlässt meist verbrannte Erde, sollte aber deswegen kein Tabu sein. Auch eine Trennung kann eine Lösung sein. Es stellt sich die Frage, in welcher Funktion will ich intervenieren. Als
- Aufmerksammacher (Winken mit dem Zaunpfahl)
- Berater und Tippgeber (Vorsicht: Parteilichkeit, Einseitigkeit, missverstanden werden, zur eigenverantwortlichen Klärung motivieren)
- Moderator/Mediator (Wichtig: gute Gesprächsstruktur, Zeit, Regeln, Ausgewogenheit, Schutz, Vertraulichkeit)
- Leader (Machteinsatz, klare Vorgaben, Kontrolle, echte Konsequenzen)
- Auftraggeber an externe Mediation (Delegation an Dritte, klarer Auftrag, Profi aussuchen, Ziele für die Streitparteien setzen, unbedingt Nachkontrolle)
Stimulierung. Ein Arbeitskontext ohne jeglichen Konflikt oder zumindest ohne jegliche Auseinandersetzung (eine Vorstufe mit Konfliktrisiko), in dem ständig nach Harmonie gestrebt wird, ist häufig eingeschränkt kreativ und mittelmäßig leistungsfähig. Man spricht dann etwas zynisch von „Schönwetterführung“. Deshalb kann und muss es bei Bedarf auch Führungsaufgabe sein, Mitarbeiter zu ermutigen, konfliktbereiter zu sein und Auseinandersetzungen, wenn sinnvoll, auch zu riskieren und einzugehen. Einzelgespräche, Coaching, Teamentwicklung, Seminare sind z.B. Instrumente zur Stimulierung. Stimulierung muss immer offen betrieben werden. Keine Maßnahmen „von hinten durch die Brust ins Auge“, damit die Mitarbeiter mal sehen wie „feige“ und „harmoniesüchtig“ sie sind. Das ist aus meiner Erfahrung äußerst kontraproduktiv. Also das Thema bei Bedarf direkt ansprechen, Mut machen, Hilfestellung geben, Kommunikationsräume schaffen (einzeln und im Team).
Also ran an die Konflikte! Wenn sie schon keine „Lust“ sind, dann sollten sie auch keine „Last“ sein, sondern funktionaler Teil der Aufgabe, Teams in ihrer Selbstorganisation zu begleiten und zu führen.
Tipp: Führungskräfte können den Umgang mit Konflikten lernen – zum Beispiel mit dem Scrum Supplement “Konfliktlöser”
- Konfliktlösung – eine Kurzanleitung
- Führung und Management in Spannungsfeldern (Teil 2)
- Vom Umgang mit sozialer (Un)Ordnung und Struktur in agilen Systemen
I’ve recently spent a bit of time working with people on their graph commons and a common pattern I’ve come across is that although the models have lots of relationships there are often missing nodes.Emails
We’ll start with a model which represents the emails that people send between each other. A first cut might look like this:
The problem with this approach is that we haven’t modelled the concept of an email – that’s been implicitly modelled via a relationship.
This means that if we want to indicate who was cc’d or bcc’d on the email we can’t do it. We might also want to track the replies on a thread but again we can’t do it.
A richer model that treated an email as a first class citizen would allow us to do both these things and would look like this:
We could then write queries to get the chain of emails in a thread or find all the emails that a person was cc’d in – two queries that would be much more difficult to write if we don’t have the concept of an email.Footballers and football matches
Our second example come from my football dataset and involves modelling the matches that players participated in.
My first attempt looked like this:
This works reasonably well but I wanted to be able to model which team a player had represented in a match which was quite difficult with this model.
One approach would be to add a ‘team’ property to the ‘PLAYED_IN’ relationship but then we’d need to do some work at query time to work out which team node that property value referred to.
Instead I realised that I was missing the concept of a player’s performance in a match which would make some queries much easier to write. The new model looks like this:The tube
The final example is modelling the London tube although this could apply to any transport system. Our initial model of part of the Northern Line might look like this:
This model works really well and my colleague Rik has written a blog post showing the queries you could write against it.
However, it’s missing the concept of a platform which means if we want to create a routing application which takes into account the amount of time it takes to move between different
If we introduce a node to represent the different platforms in a station we can introduce that type of information:
In each of these examples we’ve effectively normalised our model by introducing an extra concept which means it looks more complicated.
The benefit of this approach across all three examples is that it allows us to answer more complicated questions of our data which in my experience are the really interesting questions.
As always, let me know what you think in the comments.
I have noticed that all systems have some natural capability for
productivity, value delivery and quality. As the people in the system
gain experience in the system, their performance will start reaching
that systemic speed. Just like with a ship, this happens quite easily,
but when the “hull speed”* is reached, the amount of effort / power to
go faster dramatically increases, up to the point that a certain speed
seems unsurmountable regardless of power expended. In systems, we can
perceive this e.g. in overtime, which does not yield real benefit
since the extra effort translates to more mistakes and other negative
factors that detract from real progress.
I continually observe that also in the ball point game, where people
psyche themselves to try harder, but they still get the same result.
Also, waterfall has a certain hull speed. No amount of pressure will
make it deliver stuff faster.
Organisations, as they are composed, also have a hull speed.
The only way to go faster than the hull speed is to change the system
into one that has a higher hull speed. E.g. starting to use Scrum. But
any given set of practices also have a hull speed. And the only way to
go faster (after the learning period) is to change the practices to
ones with higher hull speed.
Thus, we can say that any action that does not affect the system’s
structure and fundamental behavior in some way (and merely is an act
to “shape up”, “increase discipline”, or “try harder”) is very
unlikely to produce any lasting effort. Any benefits gained from such
activities either produce negative side effects that ultimately cancel
any positives, or disappear over time as the system returns to its
TL;DR: Work smarter, not harder.
* I know that hull speed is technically a little different from that,
but a layman’s approach is good enough for this concept :).
Great news for those out there in the Greater Toronto Area and Southern Ontario: Berteig Consulting Inc. and three additional partners have launched our new business: Real Agility Staffing – Connecting Great People to Great Companies in an Agile Way! If you are searching for a job, or even just thinking about your career possibilities, please fill in our survey about your skills and experience. We have two initial open positions for senior agile practitioners related to quality and software development. Let us know if you are interested or know someone who is.
Eventually we hope to grow to other geographical regions so if you are outside the areas I mentioned, please feel free to do the survey to let us know about your existence
User stories are intended to be a high level description of some functionality. It is, however, common to find user stories growing into specs or large use cases that resemble whatever the organization used to do, back when they did large requirements documents. Comments like “The stories are not detailed enough to start development” or “This took much longer than expected so we should have more acceptance criteria for next time” can become common. There is a balance here that we should watch and adjust carefully. And most of the time we think the solution is more story documentation.
I like user stories as an easy to understand idea for a company to start thinking about a light weight way to communicate needs, features and benefits. It is hard to describe in brief sentences all the forces that pull organizations to keep them thinking in lots of details. A few might be:
- A culture and history of Big Design Up Front that makes it hard for feature definition to happen just in time.
- A continued need for long range planning requiring estimates for work that will possibly take months before it actually starts.
- Skilled technical people who are accustomed to talking about technical details instead of the needs of the user.
- And more…
The most powerful and subtle force to cause “user stories” to grow is a continued lack of focus for the people defining features and those creating the features.
For example, if I am Product Owner of 5-12 products working with 3 teams who are all working on multiple products, I am not able to think of a feature, collaborate on it’s definition as it is built, see it created and then think about the next feature. I have to document my thinking of every feature because one hour from now I have to think about other features that also might not be built right away.
The key to being truly Agile is to finish stuff. The more inventory of ideas, features, undeployed code, etc. that we have, the less Agile we can be.Have Conversations
In short, Ron Jeffries, the inventor of User Stories, said that the user story should have “3Cs” of attributes: Card (small enough to fit on an index card), Conversation (is a place holder for conversation) and Confirmation (a definition of when we are done, such as acceptance criteria). Most of the symptoms prevalent when stories grow big are likely indicators that the Conversations are not taking place and people are writing stuff down in an attempt to fill the gap.
Don’t write more stuff down. Figure out why the right conversations are not happening. i.e. “Individuals and interactions over processes and tools.” That said, sometimes what we see as an over-documented abuse of the user story is a vast improvement on what the organization used to do. We have to temper our zeal with a dose of client reality as we work to get incrementally better.
Do you see user stories getting too big? If you don’t use user stories, does what you use help or hinder conversations? What is your balance between the ability to deliver vs. the need to document thinking?
Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.
Sometimes Twitter is just a bunch of crap and noise.
Other times, stuff comes over that you just can’t ignore. After we published the State of Agile report, I had one of those moments.
It hit me after one dude tweeted something to the effect of: “How in the world can a team claim to be doing Scrum if they don’t practice retrospectives?” I couldn’t let this one go. I polled our staff of professional agile coaches. Within an hour, 6 of them had opinions on whether you can proudly call your team “Scrum” or even “Agile” without conducting regular continuous improvement procedures.
Here I’d like to share with you some of our coaches’ opinions and recommendations – then find out your take. (ADHD moment: If you are new to agile or wondering ‘what is a retrospective?’ here’s a good explanation).
Take this as FREE advice from our professional coaches. Normally you pay for this stuff so IF you enjoy it, you at least owe me a LinkedIn share or tweet @VersionOne.
WHAT THE VERSIONONE COACHES SAY…
“You can’t be ‘Scrum’ if you aren’t doing all of the practices of Scrum.” – Steve Ropa
True. But I give this statement a big “So what?” Isn’t the goal of agility to create great software? If some part of Scrum doesn’t work for your team, should you do it anyway just so you can be Scrum? In the words of John Pinette, I give this a “nay nay.” I recommend doing all of the practices to start with – and only removing or modifying practices when you find them to be unnecessary or even detrimental. Ironically, teams usually come to that conclusion during the retrospective.
You can be agile without retrospectives, but it’s a very, very rare team who can. I have run into a few. They’ve usually been doing XP for a while, and are always co-located. Some teams did the retrospective because they were supposed to, but never really came up with anything new. What they were able to do was to inspect and adapt at the drop of a hat. These teams also found that daily standups had become redundant.
“It’s the wrong question to begin with.” – Lowell Lindstrom
The question of whether or not a team can be “Scrum” is a red herring for a few reasons.
First, due to the inherent inspect-and-adapt nature of Scrum, over time, no two teams will be identical and any given team may evolve in a way that makes one of the common or defined parts of the Scrum framework suboptimal. The classic example of this is task articulation and estimation in Sprint Planning, which many agile teams find is not necessary as they improve.
Second, there is no one person who can designate whether or not a team is Scrum, leaving any assessment to the discretion of the assessor. Across experts in the various Scrum communities there is a little consensus. This is due largely to the first point, i.e., the fact that each person’s opinions will be shaped by their experiences. And these are inevitably different.
It’s worth noting that the original definition of Scrum didn’t even include retrospectives. The patterns and papers from the mid-90s, and Ken Schwaber’s first book on Scrum (2001) make no mention of retros. The focus was on the product with the Sprint Review at the end of each Sprint, but no explicit reference to the team’s PDCA. Similarly, the original definition of Extreme Programming (XP) did not include retrospectives.
In 1999/2000 as XP was gaining in popularity, Norm Kerth was writing his book Project Retrospectives: A Handbook for Team Reviews. Although focused on larger, longer projects and the difficulty of learning what really happened, the ideas resonated strongly with the XP community and we soon saw the practice added to the XP list. The Scrum community followed suit and in Ken’s next book on Scrum (2005), we see retrospectives become part of the framework as we know it today.
So, were teams doing Scrum from 1993-2005 not considered ‘Scrum teams’ because they didn’t do retrospectives? Of course they were; it’s a silly question. What we can say is that the Scrum community and its leaders have found that the most hyper-performing teams reflect on their practices with a tenacious attitude toward improving the way they develop. Most do this through the construct of the retrospective. However, doing retrospectives well is difficult and depends on a culture that values learning. So, if my retrospectives suck and yield no improvement, then am I really any closer to being Scrum than if I do not do them at all? I would argue: No. Is a team who uses most of the Scrum framework but not retrospectives, integrating PDCA into their daily work as the Kanban community advocates, still a Scrum team? I would argue: Yes.
Any discussion centered on “being” Scrum or “doing” Scrum should explore whether a practice improves a team’s performance, the different scenarios and conditions required for a practice to thrive, and the substitutes that might make a practice replaceable.
“Retro is a key ceremony. You cannot be ‘true’ Scrum unless you follow the framework as it was designed.” — Jo Hollen
You can, however, be “ScrumBut”… and realize some value from your partial Scrum efforts.
Going back to agile and Lean principles, the notion of continuous improvement is very foundational. Without retrospectives, I would be concerned about how the culture is addressing the principle of continuous improvement. Do such organizations have other methods through which they can incorporate team feedback and address improvement? Maybe the more interesting examination is why do they NOT want to do a “retrospective” – or not think they need to? I’ve seen where they were done as part of the process, but often I felt they were not very effective in many teams.
First, it must feel totally safe to bring up something that is not going well. Many cultures still want to immediately find a person to blame for the “problem.” If anyone feels unsafe, the retrospective will be superficial. Nothing useful will come from it, and the team will quickly find the retro a waste of time.
Even if a team gets to the point of bringing up real issues, there must be a spirit of appreciation for the input – then real results and follow-through. If nothing ever comes of the feedback, it will quickly stop. Besides, if results are not implemented, then there is no improvement anyway (thus, another waste of time).
Or maybe the team feels that everything is fine. REALLY??? Nothing can be improved? (Maybe you should hire them for coaches then). Even the highest-performing teams will find things that can be improved. But, maybe every two weeks feels too often? Maybe they should do a health-check/status and a deep-dive examination every few sprints. Agile requires some form of engagement and commitment to continuous improvement.
“You can’t be ‘Scrum’ without the ‘Scrum’ ceremonies.” – John Krewson
You can be agile without the ceremonies so long as you’re adhering to the principles, but “Scrum” asserts certain ceremonies as part of the framework. Those ceremonies, retrospectives included, are intended to uphold the theory of empirical process control upon which Scrum was built. I refer to retrospectives as the “missing agile value” and have a blog post coming out soon to address this.
“Learning always precedes agile maturity.” — Brian Irwin
As you’ll see in John’s blog post, from an organizational perspective, learning always precedes agile maturity. I’m also planning a blog post specifically about expanding retrospectives past the team level and embracing them at all levels in the organization, including (or especially) at the upper-management level.
To me, one of the most critical aspects of agility is learning; i.e., at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Maximizing learning is also a key Lean concept.
I think people tend to get so hung up on processes and how to do things that they forget why they’re doing them in the first place. But to answer the question directly, if you’re not doing retrospectives not only are you not doing Scrum—you’re not really agile if you aren’t making time for learning. Teams typically stop doing retrospectives because they’re difficult. Once you’ve addressed the low-hanging fruit, it gets complex to address the real hard stuff (people issues, organizational dysfunction, etc.).
“Not doing retrospectives suggests the plan must be perfect.” — Michael Moore
I would say that this is not specific to Scrum so much as it’s one of the principles of agile to inspect and then adjust/tune. This principle goes beyond agile even; I’m not sure I’ve seen any good improvement method that doesn’t include some sort of periodic reflection and adjustment, whether it be self-improvement or organizational.
Not doing retrospectives suggests that there is no need for adjustment, which means that the team and plan must be perfect. If they aren’t, however, this activity is essential to maximizing effectiveness.
Of all the principles, this is the first that should be implemented, regardless of the method. From this principle, all other principles and practices are discoverable.
WHAT’S YOUR OPINION?
Can a team be Scrum or Agile without retrospectives? Join the debate by leaving a comment below. Better yet, subscribe to this blog; several articles addressing this topic are on deck from our coaches in the upcoming Agile Chronicles. We’d like to hear from you!
Heroku And SSL: Fixing “This site’s security certificate is not trusted!” on Android and other devices
I recently received a report of SignalLeaf being “blacklisted” by Chrome. After a bit of panic, and asking twitter to see if the site was having issues, I got confirmation that Android phones and other devices / browsers were getting a security warning about the SSL certificate I had installed on SignalLeaf.
This sent me in to a bit more of a panic, as I had no clue what was wrong or how to fix it. Time to start googling error messages and random combinations of words related to the services I’m using…DNSimple, Heroku, RapidSSL And Certificate Chains
I use DNSimple for my domain name hosting (if you’re not using DNSimple, I feel sorry for you, having to put up with other services). I also use Heroku for hosting SignalLeaf. This is an epic combination of awesome when it comes to buying and setting up an SSL certificate. So awesome, in fact, that Heroku uses DNSimple as the canonical example of how to set up SSL in their help pages.
When you buy an SSL certificate through DNSimple, it is issued through a service called RapidSSL. This is a legit service, and the certs that you get are as good as any other cert. The “issue” that I ran in to, is that RapidSSL is not yet trusted on every browser and device around the world. They have not been around forever, and are not as big as some other certificate authorities, so they don’t have trusted status everywhere (yet). But like I said, they are legit and they are certified by GeoTrust to prove their legit status.
Because RapidSSL is not a big name certificate authority, and because they are not yet trusted by every browser and device, yet, you need to install a set of intermediate certificates on your server, when you set up a RapidSSL certificate. This certificate “chain” provides the authority that older browsers and devices need, in order to completely trust RapidSSL certificates.Setting Up A Certificate Chain On Heroku
The Heroku help files show the basics of how to set up a chain of certificates, by creating a “.pem” file – this is a group of certificates that form a certificate chain, concatenated in to a single file. Heroku also recommends grabbing a specific PEM bundle for RapidSSL, but it doesn’t really say what to do with it.
After some additional digging and some help from the DNSimple people (have I mentioned how awesome they are?), I figured out that you need to install the PEM file with your certificate. Assuming you have a “server.crt” for your actual certificate, a “bundle.pem” file for the RapidSSL bundle, and a “server.key” for your server’s secret key, the command you want to run is this:
heroku certs:add server.crt bundle.pem server.key --app my-app-name
This will install the actual SSL certificate along with the RapidSSL bundle.pem file (from the link above), and verify everything with your server’s SSL key. (The --app my-app-name option is only needed if you are running this command from a folder that is not already tied to a Heroku app instance.)Updating A Certificate Chain On Heroku
If you’ve already installed your certificate but you need to update the chain or the certificate itself, run certs:update instead of add.
heroku certs:update server.crt bundle.pem server.key –app my-app-name
This will update your app with the right certs and chain. Heroku will warn you that this is potentially destructive, so be sure you have the right certs lined up. Confirm the update and you should see an instant trust on your site certificates.Fixing The “Key could not be read since it’s protected by a passphrase” Issue
Along the way to fixing my SSL certificate, I ran in to this error message. I found a StackOverflow question that said this happens when you have an older version of the Heroku Toolbelt installed. It turns out I had an old one on my system Ruby version. I had installed the original Ruby Gems version of the Toolbelt a few years ago. For various reasons, my default Ruby version changed a while back, but I reset it to the system ruby recently. Doing this caused the old Heroku Toolbelt to be the one in use on my system. To fix that problem, I had to uninstall the old toolbelt:
gem uninstall heroku-toolbelt
and then install the latest version of the toolbelt (through Homebrew in my case)
brew install heroku
Once I had the right version of the Heroku Toolbelt installed, the error went way and I was able to install the certificate chain.This Is Still Easier Than It Used To Be
For as many problems as I had getting this fixed, this is still 1,000 times easier than it used to be. I remember the days when buying an SSL certificate cost several hundred dollars and required a verification process on your business in the United States. It took weeks, certificates were mailed to you (not email… actual mail), and installation / configuration of SSL often took hours or days. If you got something wrong in the initial configuration, you would have to start over.
These days, with DNSimple and Heroku, buying and setting up an SSL certificate took me less than 1 hour total. It was only because of a mistake that I made and not understanding the need for intermediate certificates that I had these problems. Even with these problems and the few hours of research and troubleshooting, I am more than happy to have paid a small fee for the SSL certificate, and the monthly fee to host on Heroku with SSL.
Post Footer automatically generated by Add Post Footer Plugin for wordpress.