Last week Justin, our Director of Product Engineering, shared how instituting a simple template makes code review easier for our dev team.
We do a bunch of code reviews at Sprint.ly. One of the things we’ve done to make that process a little easier is institute a code review template. This template is a free-form list of questions that every person filling out a pull request uses.
I’ve just been named to one of the 100 top management experts on Twitter. See Keeping Up with #Management:100 Experts on Twitter. You have to page down under “Executive Coaching” to see me.
I’ll return to editing my “Design Your Agile Project” series now. It needs serious editing. That’s why you haven’t seen the next post yet.
Choice Hotels International, Inc. is one of the largest and most successful lodging companies in the world -- representing more than 6,000 hotels and half a million rooms. Last year the company launched its SkyTouch Technology™ division to provide property management solutions -- reservations, guest stays, and rates -- via a cloud-based platform that users can access from any Internet-enabled device, including smartphones and tablets. The company’s president and chief executive, Stephen P. Joyce, believes the spun-off division will breed new initiatives and “accelerate the pace of innovation.”
SkyTouch Technology’s Hotel Operating System™ was originally developed in-house as a proprietary platform for monitoring hotel efficiency, property management, and other business functions. The system supports clients across the industry, from small hotels to large properties. With more than 5,500 successful installations, it’s currently the most popular property management system in the world.
SkyTouch Technology partnered with Rally because it wanted to set a solid foundation from the get-go. The company is adopting the SAFe® model to drive an Agile transformation, with a clear focus on getting to market quickly. “It’s paramount that we do it right from the beginning because we’re setting our foundation and a course of action going forward,” says Rebecca Knight, Manager, PMO, at SkyTouch Technology.
“What we can build now and capitalize on -- what we’ve done well with the Scrum-level projects and built up to the portfolio management level, and connect to our strategy -- is going to be key to our success, getting to market quick and beating our competition.”
Consistent with agile principles, customer input is a critical and highly valued part of the SkyTouch Technology development process; 60 percent of the OS’ new features come directly from customer feedback. Scaling agile has helped the company make the right things for the right customers, and get to market faster with the best quality products.
“Rally is bringing a lot of value to SkyTouch … not only from a product (quality of the features and mapping to how we can expand and evolve, as our culture is changing and evolving), but also from a coaching and technical expertise [perspective].”
Agilen Entwicklungsmethoden hängt immer noch der Ruf unzulänglicher Dokumentation nach. Gerade in hoch regulierten Branchen wie der Medizintechnik geht es um Verifikation und Validation der Entwicklung, um Rückverfolgbarkeit der Anforderungen und um ein gescheites Risikomanagement. All das macht durchaus Sinn, will man doch sicher gehen, dass ein Produkt am Ende das tut, wozu es entwickelt wurde.
Da ist die Vorstellung von Scrum-Teams, die allein von Sprint zu Sprint planen, natürlich ein Graus. Dennoch passiert genau das immer wieder: Die Entwicklung ist viel zu sehr auf die nächsten Schritte fokussiert, es fehlt jegliche Besinnung auf die langfristigen Ziele und die regulatorischen Bedingungen, die zwingend zu erfüllen sind. Wenn ich neu konstituierte Scrum-Teams dann frage, weshalb sie mmer nur von Sprint zu Sprint leben, dann wird schnell klar: Sie sind es gar nicht anders gewohnt. Es ist ja nicht so, als ob die Dokumentationsarbeit in klassichen Entwicklungsprojekten funktionieren würde. Hier wird häufig ganz zum Schluss “nachgearbeitet”. Unvergessen bleibt mir ein Projektleiter, der sich kurz vor Produkt-Launch tagelang im Home-Office einschloss, um den (O-Ton) “Q-Rotz” fertigzustellen.
Wenn wir z.B. in der Medizintechnik agile Produkte entwickeln möchten, dann dürfen wir nicht zu konservativ oder ehrfürchtig vorgehen. Es kann nicht darum gehen, bestehende Prozesse mit Scrum abzubilden – dann brauchen wir erst gar nicht mit dem agilen Change anzufangen. Es geht vielmehr darum, mit Scrum einen neuen Prozess aufzusetzen, der das Thema Dokumentation zuverlässig in den Griff bekommt. Und hier sehen wir vor lauter Bäumen bisweilen den Wald nicht mehr: Das Skelett, das Grundgerüst von Scrum, ist nichts anderes als ein Validationstool. In regelmäßigen, kurzfristigen Abständen wird geplant und anschließend verifiziert, ob das Geplante tatsächlich erreicht wurde. Diese Verifikation findet nicht nur auf funktionaler, sondern auch auf formaler Ebene statt. Wenn beispielsweise jede entwickelte Funktionalität nicht nur in gewisser Weise funktionieren, sondern auch in bestimmter Weise getestet und bewertet sein muss, dann lässt sich diese Anforderung über eine Definition of Done abbilden.
Spannend dabei ist: Meistens stellt sich heraus, dass Scrum-Teams noch gar nicht in der Lage sind, von Sprint zu Sprint die dokumentatorischen Anforderungen zu erfüllen. In Scrum fällt so etwas schnell auf – das Team wird am Ende eines Sprints einfach nicht fertig. Sie haben zwar entwickelt, aber das Drumherum fehlt. Also kann der Product Owner die Ergebnisse nicht abnehmen und die Aufgaben wandern zurück ins Backlog. Wenn wir jetzt nichts unternehmen, dann sind wir wieder im klassichen Projekt: Es türmt sich ein Haufen unerledigter Arbeit auf, sodass am Ende der Entwicklung nichts wirklich fertig ist.
Hier hilft Scrum, indem es das ganze Ausmaß der Unzulänglichkeiten offenlegt. Und zwar alle
zwei Wochen. Am Ende läuft es darauf hinaus, dass das Scrum-Team lernen muss, wie Dokumentation funktioniert. Dazu brauchen sie Unterstützung von Experten, die meistens aus der QM-Abteilung kommen. Häufig sieht eine QM-Abteilung ihre Mission darin, die Entwicklung zu überwachen und auf Missstände hinzuweisen bzw. diese auszubügeln. Dadurch wird der Entwicklungsprozess an sich aber nicht verändert, denn die Zweiteilung zwischen Entwicklung einerseits und Qualitätsmanagement andererseits bleibt bestehen. Eine Möglichkeit, diese Zweiteilung aufzuheben, ist die Eingliederung der QM-Experten in die Scrum-Teams, damit praxisnaher Wissenstransfer statt finden kann.
Das Erfüllen von dokumentatorischen Anforderungen ist kein irrsinnig komplexes Unterfangen. Da ist nichts drinnen, das den menschlichen Verstand übermäßig herausfordern würde. Aber es will gelernt sein. Das ist in anderen Bereichen nicht anders: Für viele Entwickler ist das integrative Testen eine Selbstverständlichkeit, ohne dass sie niemals etwas als lauffähig präsentieren würden. Aber auch das war nicht immer so.
Mit Scrum haben wir die Möglichkeit, Teams aufzubauen, die sich mit regulatorischen Anforderungen so gut auskennen, dass ihre Berücksichtigung eine Selbstverständlichkeit wird. Dann – und erst dann – können wir davon sprechen, dass das Team mit dem letzten Sprint fertig ist und das Produkt auf den Markt gehen kann. Alles andere ist Augenwischerei.
Recently, while working with one of our customers the topic of heroics came up… okay, this comes up all the time
It seems hard to argue with heroics, from the time we were young we’ve heard stories of heroes in our family tree or national history. The term is attributed with acts of valor and selflessness.
Upon closer examination, frequently we find that the heroics that are being described in many enterprises could be better attributed with undisciplined, or even un-intentional delivery….
How do you define a hero in your business?
How does your business define a hero?
How do you reward the heroes?
A bunch of companies define a hero as someone who swoops into a project to save the day. They work a ton of overtime and get the job done by slaying the vicious dragon. They are capable of quickly stitching up a troubled problem just enough to get it to market.
It’s time for this paradigm to change.
When transitioning to agile there is a high value placed on one of the 12 principles of agile development, the indefinite, sustainable pace. Given the traditional “hero”, we immediately have a conflict. So let’s change the definition of the hero.
- What it is not:
- working overtime
- being the goto guy
- taking over for others
- saving a project at the last minute
- the number of bugs you find
- the total lines of code you write
- What it is:
- Sharing in successes and failures with the team
- Practicing commander’s intent by helping the team generate new ideas of how to achieve a goal with an unknown path.
- Demonstrable selflessness in self promotion
- Creating a new team option by developing a new Generalist skill
- Reducing team cycle time
This blog was co-written by Isaac Hogue.
Helen Meek is an experienced Agile Consultant and Coach with a passion for helping people, teams and organisations succeed and meet their full potential.
It’s been a pretty interesting couple of weeks with my adventures taking me to Kingston for a new client (note don’t get on slow train!), holding the Agile Coaching Exchange with Liz Keogh, and waving good bye to a client I have spent the last 15 months with.
For those that couldn’t make the exchange this month you missed Liz talking about complexity theory, and I have admit she managed what two others couldn’t do and that was to really help me to understand what Cynefin is. I think the breaking point was the inclusion of an exercise that made it seem real to me, and working in groups that helped to reconfirm the learning. I am not sure I am ready to write a blog about Cynefin yet, so I have included a few photos of the event and a link to Liz’s blog who covers it a whole lot better than I would. Thank you Liz!
Next week I am pretty excited to be attending the David Anderson Train the Trainer Class as part of the Lean Kanban University. It will be the first time I have met David and I am hoping to extend my knowledge further to really support driving good Kanban in organisations. It doesn’t hurt either that it’s in Turkey. I am sure I am going to have loads of good stuff to blog about on my return.
Photo of actual place of learning (wooooooooo!)
So my topic of the week is something that my colleague Mark Summers and I presented recently at both Scrum Gathering Las Vegas and XP2013 Vienna. It is also something that we both are very passionate aboutGrowing ScrumMasters for the Future.
The challenge we faced was an organisation that was growing vastly in size and with an enormous intake of new ScrumMasters, who had a varied degree of experience and knowledge. We wanted to be able to support them in their knowledge and create a safe learning environment for them to put key skills into practice. From that point forward the ScrumMaster Education Programme was created.
Over the 6 month period that we ran the programme I put together an experience report of what we did and learned. I wanted to share with you that report so you can read and see the success that we had. Building this programme and watching our ScrumMasters grow was something that I took great enjoyment from and something that I am pretty proud of.
Even though I am leaving this client, I am happy in the knowledge that we have built a strong community of practice, and that they will continue to educate themselves without me. I have no doubt that we have been nurturing the Agile Coaches of the future.
Good bye guys, I am going to miss you all.
Learning is often something that gets pushed to one side when all hell breaks loose in the office. We practice Continuous Improvement in our teams, so why do we fail at doing this personally?
My mission for you is to learn something new this week.
This post first appeared on Helen’s blog in June, 2013.
I have a nice learning activity to illustrate the benefits of product owners participating with teams. It is also about the team’s responsibility to make good use of the product owner’s time. It’s called the Pumpkin Head Activity.
You need a flip chart and a marker for each group. You need to download 3 simple pumpkin head stencils. Keep it simple. Here are some examples when I Google simple pumpkin head stencils. Order the stencils in order of complexity, simplest first.
Form groups of 4-6 participants. Read the following Activity Description to all of the participants.Activity Description
- The product owner will describe an image
- The Team draws the image
- PO never shows the image to the team
- Team can ask questions
- It may be an image of a pumpkin head
- Run three rounds with a different image each time, about 10 minutes per round
Ask them to select a member to serve as product owner. Ask the product owners from each group to meet with you.Product Owner Instruction
- Give each the ordered drawings.
- Repeat the instructions
- Ask them to ensure the team does not see their drawing (use a workbook or folder so the other participants cannot see through the paper).
- Ask them not to use their hands to describe the image or point to corrections (they can’t help themselves)
- The Phone Call round
- PO cannot look at the drawing. Have the product owner stand behind the easel or with their back to the drawing.
- Debrief. Discuss why this is hard, unfair, nearly impossible.
- Face to Face round
- Product owner can look as the team draws. But product owners can’t use their hands.
- Discuss the benefits of fast feedback. Can teams get too much feedback?
- Accelerate Feedback round
- Product owner describes an increment (the left eye for example) then waits. At least 3 members draw what they think they heard. The product owner picks the closest one and describes modifications, then waits. The team iterates.
- Debrief. Discuss the benefits of incremental and iterative approach to accelerate feedback. Who is responsible for providing the opportunity to accelerate feedback?
This is frequently one of the groups favorite learning activities. Once the group has finished ask one more debrief questions. How did the team feel about accomplishing the drawing? How do the product owners feel? Teams can get very enthusiastic about accomplishing this task. Imagine if our work life was this exciting.
So you are sitting at your desk wondering how come your beautifully and carefully-thought out abstractions have turned into an ugly monster, and why your precious codebase smells like a giant mess? You may be not the smartest guy around but you are not that stupid or unqualified after all.
Well, just accept that your code sucks and stop worrying about it. Even the most brilliant programmers I know come up with the messy code or leaky abstractions sometimes. To fail is human. The business requirements come and go, the product evolves, you are growing as a professional. Don’t be OK with it, just stop torturing yourself trying to find the 100% perfect solution. If it works for now and it looks easy enough to be changed later, then it’s probably fine. On a side note, I would rather wonder why you are OK with any code at all. If you can’t spot an issue here or there then you are probably just not skilled enough to see the defects.
I’m not talking about some ‘forget the code, WE ARE SHIPPING THE PRODUCT HERE, B**TCH!’ management bull**t. The beautiful code and design is what makes your product easy to maintain and improve in the long run. The more skilled and experienced you become, the more likely you are to fall into the “disappointed in everything” mental trap. Try to think about it rationally – you’ve been around for quite some time, you’ve built some great stuff, your projects haven’t fallen apart as a consequence of awful technical decisions. And though your code sucks from your point of view, perhaps it’s not that bad on the absolute scale of code awesomeness.
What can we do make it less painful? Code review really helps a lot. Some developers complain about code review not being effective enough, i.e. it only helps you find the most basic formatting and code issues. I was a bit skeptical myself not so long time ago, but even if it helps to fix the formatting and minor code issues, then it’s a great improvement! I would say it’s a matter of trying and figuring it out for yourself. From my experience, early code reviews help to avoid possible design pitfalls, for example, if a developer hasn’t considered a specific use case of a module he is working on. What’s even more important is knowledge sharing. Two heads holding the feature implementation details are definitely better than one (you never know, this lonely developer working on some sophisticated data processing logic may get hit by an asteroid the next day).
Try and fail, learn from your experience. Reading books on code quality doesn’t help. Unless you’ve suffered from the f**ed up design or messed up code, you won’t understand why it’s important to think about future self supporting the codebase.
The code sucks. Repeating this statement makes no sense. What does matter is understanding why it sucks, accepting the trade-offs and constantly thinking about the ways to improve it.
Den passenden Job zu finden ist offensichtlich genauso schwer wie den passenden Mitarbeiter auszuwählen. Man sollte meinen, die Recruiter hätten die „Qual der Wahl“ vor lauter Arbeitsuchenden klugen Köpfen da draußen. Dem ist aber nicht so. Also nicht, dass es keine klugen Köpfe gäbe – es herrscht wohl eher eine Inkompatibilität mit den vorhandenen Arbeitsplätzen.
Junge Absolventen haben offensichtlich das Interesse an klassisch geführten Unternehmen verloren. Sie haben keine Lust auf Hierarchien und die damit verbundenen politischen Machtspielchen. Heutzutage möchte man lieber die Welt verändern und einem sinnvollen Beruf nachgehen, anstatt den Business Value eines Unternehmens zu erhöhen. Manch Personaler schüttelt den Kopf über diese “verträumte” Einstellung. Man kann doch nicht den gesamten Arbeitsmarkt auf den Kopf stellen, nur wegen dieser heranrückenden Generation Y, die offensichtlich noch nie den Ernst des Lebens gespürt hat! Die Generation, die nach 1980 geboren wurde, und alles hinterfragt – den Vorgesetzten, den Sinn der Arbeit und die Ziele der gesamten Organisation.
Gerade in Unternehmen, in denen agil gearbeitet wird, haben wir es mit vielen solchen “Ypsilonern” zu tun. Junge ScrumMaster, die ihren Vorgesetzten auf Augenhöhe begegnen, Themen eigenverantwortlich vorantreiben, Impediments lösen und langsam ihr ganzes Umfeld verändern wollen. Allerdings stoßen sie mit diesem Verhalten auch schnell an die Grenzen der Organisation. Zum Beispiel an Teamleiter, die ihre Position verteidigen und sich von den, als hierarchisch niedriger eingestuften ScrumMastern, nichts sagen lassen. Starre Strukturen, die sich auch mit viel Elan und Ausdauer nicht brechen lassen. In einem solchen Umfeld resignieren ScrumMaster häufig – und kündigen früher oder später.
In diesem Falle stehen die Recruiter wieder vor der herausfordernden Aufgabe, die offene Stelle passend zu besetzen. Doch wie anfangs erwähnt, ist das gar nicht so einfach, eher zermürbend. Vielversprechende Bewerber werden letztendlich doch wieder mit den hartnäckigen Strukturen einer hierarchischen Organisation kämpfen müssen. Entweder sie ordnen sich dieser unter, oder sie gehen. Im Falle der Generation Y wird es die letztere Option sein.
Klar kann man diesen Trend auch als solchen abtun und weitermachen wie bisher. Allerdings werden dieselben Leute, die heute als Absolventen von den Unis gehen, eines Tages das Sagen im Unternehmen haben und ihre Einstellungen werden die Arbeitswelt auf Dauer prägen. Eigentlich ist der Zug schon ins Rollen gekommen. Entweder man springt auf und ändert die alten Muster, oder man bleibt auf der Strecke und schaut, wie weit man kommt. So oder so brechen spannende Zeiten über uns herein.
- Mr. M auf bor!sgloger – Das Unternehmen
- Management 3.0
- Von “verscrumpelt” zu “verscrummed”: Agilen Frust iterativ beseitigen
Once upon a time there was a whiny Product Owner, two Team Leads, a Dev Director, an executive, and only 2 days to go in the sprint.
Enter the unplanned feature. The villainous Scope Creep we all know and hate.
But he pays our bills so we stay here late at night. And take it like a champ.
Can you guess what happens?
Watch more Prevent Agile Pandamonium videos like this
Agile teams should be holding a daily standup meeting. Don’t think of it as a daily planning meeting. Think of it as a daily opportunity to have a shared understanding of what is getting done and what lies ahead. During a daily standup meeting, participants sometimes exhibit negative personas that will detract from the meeting. As an empowered team, it is your job to self-manage and encourage good behavior. Some of these behaviors are so common, we don’t even realize people are doing them. So, I’m giving them some names. Next time you hold a daily standup, see if anyone exhibits any of these 10 behaviors. If you think of some behaviors that should be added to the list, I would love to see them.Daily Standup Meeting Negative Personas
10. Pat Decker the Obsessive Phone Checker
This person does not always pay attention and is constantly look at her (or his) phone. Did a BFF just like something? Did someone on Twitter just favorite that pic of the team board? In addition to checking her phone, she likes to share what she sees with others during the standup. “Pssst, Bob, check out this Vine video or pic on Instagram”. She’s not so loud that she’s overly disruptive but now Bob missed what someone else said during the standup.9. Stephen Craig who is Always Too Vague
This person can get stuck on the same task for days but doesn’t want anyone to know. When speaking to the team, they are crazy vague. Stephen will offer very few details until the team pushes for a deadline. He (or she) will use language like “Yesterday I was working on task 123 and today I will be working on it some more”. No other information is volunteered. When asked if they need any help, they clarify they have no blockers or risks.8. Bobbie Bainer the Team Complainer
When the attention is on Bobbie, get ready for the positive energy to be sucked right out of the room. Bobbie complains, complains, and complains some more. Management, teammates, or the technology is all fare game. Everything and everyone sucks and no one knows just how bad they have it. Don’t bring up religion or politics unless you want Bobbie to go right into a 20 minute tirade.7. Jess Jewler who loves the Water Cooler
Jess comes to the daily standup to talk, but not about what needs to be done today. Instead, he or she will talk about just about everything else. The next 15 minutes is dedicated to the water cooler. Did you see the last episode of House of Cards or The Walking Dead? Are you going to watch the Ravens play this weekend? My son plays Minecraft and constructed this totally awesome building with redstone. Anything is fair game, as long as it’s not about work.6. Billy Platitude with the Bad Attitude
Billy is a leftover from a bygone era. He was the best of the best mainframe developers and all he needs is a DLD and he’ll give you what you need… in a few months. You want any changes between now and then? Forget it! He thinks all things agile are stupid and just plays along begrudgingly. You may catch him make cynical “funny” comments at standup to point out how right he is about how stupid agile is.5. Will Funky the Non-Committal Junkie
Will does not want to be painted into a corner. Typically, he uses language like try, maybe, pretty sure, I’ll get back to you, we’ll see, would like to think, soon, almost. You’ll also see Will be the last person to comment on something and will usually go with the crowd.4. Tom Mater the Specialty Updater
Tom only gives vague commitments, usually understandable only by those in his discipline. The overall team gains little value from the statements. If you ask him for details, he’ll either tell you to look it up in a tool or he’ll be very technical in his response. Half of the team doesn’t understand what the hell he’s talking about.3. Drue Gru who thinks he’s Better Than You (and the team)
Drue has been around for a long time. He’s better than you and he knows it. If you need him, you know where to find him. He either arrives to the standup meeting late or he doesn’t come at all. He has little to say because you wouldn’t understand what he’s talking about. He already knows everything so what is he to gain by slumming with you and the team for 15 minutes? Let him know when something important happens. *sarcasm*2. Pearl Revolver the Problem Solver
Pearl means well but she lacks a sense of time. She wants to have in-depth problem solving discussions on obstacles identified during the standup meeting. She’s very curious what issues others are having because she’s going to want to talk it out and fix it right then and there. Even if there is a reserved 15 minutes after the standup, Pearl figures there is no better time than the present to tackle a challenge.1. Ian Krumpter the Interrupter
Do you listen or do you wait to talk? Stop and think about that. There is a difference. Ian waits to talk. People can be binary in that way. If you’re talking, you’re less likely to be listening. He wants to prove just how awesome he is so you’ll see him interrupt even if the topic doesn’t really apply to him.
The post Top 10 Negative Personas of a Daily Standup Meeting appeared first on LeadingAgile.
Vor ein paar Tagen erlebte ich (endlich) einmal wieder so einen Moment … einen Moment, der mich wissen lässt, dass es nicht reiner Idealismus ist zu glauben, dass Menschen Spaß an ihrer Arbeit haben und aus ihr Energie ziehen können.
Einen Moment des Leuchtens in den Augen, der Begeisterung, des Mutes, des Gestaltungswillens! Der PO – der mit dem Leuchten in den Augen – war in ein Projekt reingeraten, bei dem politische Zwänge, künstliche System- und Entwicklungstrennungen und vermehrte Absicherungsaktivitäten das Arbeiten alles andere als agil machten. Vorherige Anläufe waren bereits gescheitert bzw. die Live-Stellung war schon einige Male verschoben worden. Zur Absicherung der eigenen Abteilung ließ man höchste Vorsicht walten in der Zusammenarbeit. Man bestand auf lupenreine Schnittstellendefinitionen im Vorfeld, Abnahmen ohne Anbindung des Systems an die Schnittstelle bzw. das Frontend, parallele Abarbeitung unterschiedlicher Anforderungen und und und … Zwar wurde in 2-Wochen-Sprints gearbeitet, doch die Resultate waren für niemanden wirklich zufriedenstellend. Man hatte sich allerdings irgendwie damit abgefunden, vielleicht gerade aufgrund der Projekthistorie.
Aufgrund einer unabhängigen Anfrage des Fachbereichs/Kunden zur Umsetzbarkeit einer Funktionalität im System wurde sich der PO aber wieder darüber bewusst, was sein System eigentlich drauf hatte. Aufgrund dieses Impulses traute man sich plötzlich, das vermeintlich Offensichtliche zu denken: “Können wir nicht die Funktionalitäten, die der Kunde sich seit Jahren durch die Einführung eines neuen Systems erhofft hat, nicht auch viel einfacher im eigenen System abbilden?”
Als der PO diesen Gedanken aussprach, erinnerte er sich daran, dass er genau dies als Vision für sein neugegründetes Team vor einem Jahr formuliert hatte. Und auch damals schon war plötzlich eine Energie und Klarheit im Raum, wie sie keine schriftliche Dokumentation und Absicherung jemals erzeugen kann. Sie war positiv! Damals wie heute bei der gleichen Sache.
Diese positive Energie zeigte mir als ScrumMaster, in welche Richtung ich weiterarbeiten musste.
- Design of a complex system – Tom DeMarco
- Is educaton killing creativity?
- Design eines großen Systems – Tom DeMarco
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
What do you do for geographically distributed teams, if you want to move to agile?
First question: does the team want to move to agile? Or, does the management want to move to agile? I am serious.
I might take the same actions, but for different different reasons. In either case, the team needs to learn about what agile and lean means, and how to do agile. In both cases, the team needs help and protection from management.Why Does a Geographically Distributed Team Need Help and Protection from Management?
Managers create geographically distributed teams for many reasons. Some reasons are that there are smart people all over the world. In that case, managers create feature teams.
When managers create dispersed teams, teams with one and two people in disparate locations in far-flung locations (more than 60 meters away), managers are under the impression that “experts” can perform jobs better than teams can.
When managers think that “experts” can perform jobs better, they create bottlenecks in the work. Bottlenecks prevent flow. Bottlenecks prevent agile or lean from working. It does not matter if you want agile or lean. You won’t get either with a bottleneck. You have to overcome the bottleneck.
Can you make a geographically distributed team work in an agile way? Yes. Let’s go back to the principles.Our principles of agile or lean:
- You need to see all the work in progress.
- You want to flow work through the entire team.
- You want to see working software, sooner, rather than later.
If you, like me, don’t care how we get there, we have options.How Could a Team Take These Principles and Create Their Own Agile Approach?
Let’s take one thing at a time.
Let’s assume the team is not accustomed to working on small items of value. If you are like many of my clients, this is the case. What would it take for the team to start working on small features that deliver value?
Let’s think about the product again:
What kind of potential for release frequency does the team have? That colors the team’s thinking. The more potential for continuous deployment, the easier it is to work on small items of value.
This is where I like to introduce the notion of spikes and timeboxes. I ask the team to take their smallest feature, and work together on it. They don’t always have any notion of “together,” either. They say things such as, “We need …” and list the impediments to their ability to work together.
Now we see the need for management support.Project Management is Not a Dirty Word; Neither is Management
I know that some of you dislike the idea of agile project managers. I know some of you positively hate the idea of management in agile organizations. Let me suggest that for teams transitioning to agile, there is a place for management. That place is creating an environment in which the team learns how to self-manage.
There is no place for command-and-control project managers—never has been, never will be. Unless it’s time for lunch. Sometimes, teams need people to say, “Lunch-time!” But even that isn’t command-and-control. That’s someone saying, “I’m taking care of my need to eat. Want to come along?”
It’s the same thing for a team with a lot of risk and a lot of unknowns. A team where the normal, out-of-the-box agile solutions don’t work. Why would you let a team like that flounder?
That team needs everyone to lead. And, it often, but not always, needs someone to represent that team to management. Why? Because management doesn’t understand agile yet. That part might come now, and it might come later. But in an agile transition with many unknowns, it almost never happens at the beginning, even if management is saying, “Please go agile.”
A geographically distributed team needs management support. It does not need command-and-control. That team does need support.
That’s when I ask the person working as the project manager to start removing impediments. The team creates their own visual board. (Yes, a distributed team almost always needs a tool. I like to start with cards on a wall first, take pictures of it. Once a team knows how they like to work, then they choose a tool.) The team decides what the length of their timebox is for this feature, if they want to use iterations. They decide how to spike it. They start making decisions.
That team especially needs to understand the problem of bottlenecks, experts, and how to stop needing experts.
After they practice this a couple of times, they have the confidence they need to do this more times on their project. They can call this agile, but it might not have a real name. It’s a mishmash of timeboxes and kanban, but it works for them. Does it matter what it’s called?The Team Needs Management to Remove Obstacles
Teams might need management support. For example, I often discover geographically distributed teams don’t have enough testers. Well, you say, that team flunks the “we have all the cross-functional roles to do the work” part of agile. Yes, and what if they don’t know that? What if they want to try agile? What if they want to work through their obstacles and impediments? They need someone to represent them to their management, while they try to test as they proceed, right?
You could substitute “database admin” or “GUI designer” or whatever it is you need for tester in the above paragraph. Whenever you need someone to advocate on behalf of the team to management, you might want an agile project manager. Not someone to say, “When is the project going to be done?” Nope, not that kind of a PM. Someone to say, “What does the team need? I can help acquire that.”
PMs who provide servant leadership to the team, and represent what the team has accomplished to the rest of management can be invaluable. They can help the team understand its process and facilitate what the team can do if the team gets stuck. These are agile project management skills.
At this point, the team can try several approaches I suggested in these posts:
- Agile Lifecycles for Geographically Distributed Teams, Part 1 is for iterations and silo’d teams and a project manager.
- Agile Lifecycles for Geographically Distributed Teams, Part 2 is for kanban and silo’d teams and a project manager.
- Agile Lifecycles for Geographically Distributed Teams, Part 3 is for iterations and kanban and silo’d teams and a project manager.
You might have an even better alternative than the ones I suggested.
Do you need a project manager? No. Do you need a servant leader? In my experience, yes. Maybe in your experience, no. I would love to hear from you, if you have a geographically distributed team that does not have a servant leader.How Does This Team Evolve?
That has allowed each team to transition from the Complex to the Complicated. They now have collocated agile or lean teams. They can design their agile projects, as in Part 1. They retain the value of smart people all over the world. They don’t have the aggravation of trying to meet in different time zones for a project. They still have it for the program.
Some of my clients are still trying to make the dispersed teams work. It’s really hard. You might want to read my paper about the common problems on these teams.
Where are we now?
In Design Your Agile Project, Part 1, we discussed a straight-on approach to using whatever approach to agile, because it was obvious where you were.
In Design Your Agile Project, Part 2, we discussed looking at your system of work, and thinking about your unknowns. You need to think about your risks, and consider what you need to experiment with, to design your own agile project.
This part, part 3, is a continuation of part 2. It matters because you might need a servant leader who might be called a project manager. The title matters, because especially on a geographically distributed team, you are bridging the gap and the culture between the old way of working and the new way of working. I still think it’s Complex. Some of my clients think it’s Chaotic because they have so many impediments.
Whatever it is, you need data to take your next step.
My article, Taking the Long View in Software Development, has been published on ProjectManagement.com. Free registration is required on that site.
The point of using agile is to get finish something valuable-to-the-business quickly, to get feedback. Why? For several reasons, but the first one is so you can change the project’s priorities. The second is so you can change the project portfolio. The third is to get feedback on what you’ve done. Okay, you can exchange one, two, and three if you like. For me, those are the top three reasons to get to done every few days to two weeks. They are right behind each other in priority. Agile is all about change.
This is why every project needs to design its own way to get to done.
If you have a single collocated team, who understands how to deliver value quickly you might be in the situation described in Design Your Agile Project, Part 1.
What happens when you have more unknowns? What if your organization is “addicted” to waterfall and long projects? When you can’t see the people on your project, because everyone isn’t in the same place? When you have a lot of technical risk, such as technical debt? How about when you’re starting a program and everyone is transitioning to agile (oh please, don’t do this). Or, you’re new to agile, and you don’t have training. I have a question: would you drive a car on the road with no training, either?Rethinking What to do When Your Project or Organization is Full of Unknowns
Let’s discuss the principles of designing your agile project when you have more unknowns. Let’s start with a common problem: an organization “addicted” to waterfall and long projects. And, they’ve heard about this “agile” stuff, and they want to try it.
If you have heard about the many places Scrum has failed, this is classic. Scrum says, “replace your old culture with this new culture.” Wow, that’s a big shift. If you look at the Cynefin framework, you can see that for an organization addicted to waterfall, long projects and big requirements, they are not in Complicated. They are in Complex. Why? Because they have too many unknowns.
Here’s what I see when I do assessments in these organizations:
- Much multitasking to address emergencies.
- No project portfolio management
- Their requirements are so large, it takes them forevvveerrr to release anything
- Because their requirements are so large, and because their releases are so long, that increases the demand for emergencies: patches, interim releases, firefighting.
There could be more. This is enough.
In that case, you want to look at the Cynefin framework, and say, “What does the Complex side of the framework say?” It says we should consider emergent practice. We should not only consider out-of-the-box solutions. We have to probe-sense-respond.
What do we need to accomplish? Getting to working software, at the end of an iteration. Or, in flow. We want a feature, in flow, in a day or two, maybe three. We want completed features, with no leftover wasted work (unfinished features) at the end of an iteration. We want to be able to change what we do after the iteration, or after the feature. How do we accomplish that, from the team’s perspective? Let’s forget labels, and focus on the team.What’s the First Thing the Team Could Do?
I like to ask, “How little can we do?” Too often, the team has been asking “How much can we do?” Starting with that question helps.
Thinking in inch-pebbles, timeb0xing work, spiking work, all of that helps to learn how to work small.
Sometimes, when we have stories, and we don’t know how to break them apart, we ask, “What’s the first thing that could add value?” Maybe that’s a good question here. You could ask, “What’s the first thing the team can do?” Or, “What’s the first thing we can do that would help us get to done in a one- or two-week iteration?” Or, “How do we finish a feature in flow (kanban)?”
Often, for teams who are in the Complex side of the framework, I suggest these things:
- Start a kanban board. You need to see what your actual process is. You need the visuals.
- Decide on your work in progress limits, and stick to them, at least for a week.
- Retrospect and reflect on those limits, the progress you’ve made and anything else that arose. Where are you, as a team? What progress did you make? What do you want to keep, add, change?
Notice how this is not out-of-the-box agile or lean. It’s a way to start a team moving from the Complex to the Complicated. Once a team has been through the first week, they iterate, keeping in mind these principles:Let’s Review the Principles:
- Get to done, either in flow or iterations. Why? Because we want to develop working software.
- Keep the iterations short, either one or two weeks. Longer is not better. Why? It’s too long to allow for frequent change. Why? Because we need to allow for change in the project. That way, we can get feedback on the features, change the project’s priorities, and manage the project portfolio.
- Find a way to connect as a team, regardless of how you do so. Real-time rituals are not good if they make everybody crazy from lack of sleep. Why? We need sustainable development, even if real-time rituals are the best.
- Find a way to reflect as a team. Surrogate reflection is not good. Why? How can someone else substitute for what’s really going on in a team?
Where are we now?
Nobody has changed roles. Nobody has changed culture. We are looking at our process, and making things smaller for a while. We are reflecting. All of this in order to simplify, to move from the Complex to the Complicated.
Remember, I have only discussed what I have done with teams who are collocated, who have had problems with too-large features, long waterfall projects, and many emergencies. I haven’t addressed the issues of distributed teams yet. They are next.
I hope you stay with me as we move to part 3.
“Resource planning” or “Resource Management” or “Resource blockers” I hear these in stand-ups, or project meetings and even on CSM (Certified Scrum Master) training. People who know me watch me cringe a little each time. I have this visceral reaction that I can’t explain, my whole body cringes. Why does it matter? Some people would […]