This world has always been in need of role models. Heroes that we want to look up to striving to follow their path, their principles and ethos (if we mean business in this life, of course). For quite many years, tech entrepreneurs and IT start-up founders worship one iConic hero wrapped in myths and adoration, with zealots standing in lines any time a new iPhone is out; and it seems they’d tear apart anyone who dares not to like Apple products. As great and outstanding an achiever and innovator as Steve Jobs is, his life was far from being a glossy success story, judging by what people say and write. There’s something tragic about him, a Prometheus-like charisma, as if he’s torn his heart out of himself, lightning people’s way with a technology wonder, and then perished, chained to the rocks of self-oblivion.
May God bless Steve Jobs’ memory and let him rest in peace. There’s this other guy who looks rather laid back, than tragic, and who goes on serving the humankind. Being born same year as Jobs, 1955, he still lives and does things that reach far beyond designing devices, or making a religion out of them. Quoting from a recent Gates’ interview to the Rolling Stone magazine:
At 58, Bill Gates is not only the richest man in the world, with a fortune that now exceeds $76 billion, but he may also be the most optimistic. In his view, the world is a giant operating system that just needs to be debugged. .. Huge systems, whether it’s Windows 8, global poverty or climate change, can be improved if you have the right tools and the right skills. The Bill & Melinda Gates Foundation .. is like a giant startup whose target market is human civilization.
I am old enough to have witnessed how Microsoft evolved in the 90′s, remembering this buzz about monopolism, and the image painted out of Bill Gates as a ruthless shark.
This dynamics changed closer to the mid 2000′s. Gates was moved backstage, as if a by a scheduled scenery swap in a theater play, and Jobs came into spotlight. There’s a rush of love for Apple, people adore iPhones, and Steve acquires his ardent fanbase. He drives the Apple empire with his spirit to stand out, to leave his technological footprint in this world, and as a result he burns himself out and falls prey to cancer. We’ve also witnessed the rise of Mark Zuckerberg, but I’m deliberately not letting Mark in to the super-heroes pantheon for one obvious reason: he’s only 29, and his success is yet to stand the test of time. Although, I’d say humanity would hardly benefit too much, if at all, from Facebook and face recognition technologies (maybe security services will). Let’s see what happens to Mark as he lives up to the age of 45, at least.
Back to Jobs and Gates. They say: “The best revenge is a life well-lived”. We’re not talking about a revenge here, rather about a wise path to live this life to the fullest, as a tech, and then global entrepreneur, and to have a broad outlook on the world, going beyond the realm of digital devices and designs. Is it wise to deify a person who lost his fight to stresses, and sacrificed himself to the altar of all things “I”? Probably, there’s no finite answer to this question. It might be a matter of personal preference: some people feel more affinity with tragic heroes, who light up grey landscapes brightly and then fade away; some people appreciate the steady path of living and exploring, managing to care of themselves in such a way, so as to have as many years in this life as it can get, because more years bring more opportunities to serve the others.
There, I nailed it. Here’s the main difference between our super-heroes. Looks like Steve Jobs’ goal was to leave his footprint and be remembered for that. Bill Gates, on the contrary, seems to be more service-oriented in the way of humility. At least, the initiatives that he supports are a proof for that. Speaking of footprints, one of the projects that Bill Gates funds is a zero-CO2 emissions research, something that is very unlikely to be financed by a private or a state corporation.
All things considered, if we were to come up with the ultimate role model for aspiring tech entrepreneurs, whom would we choose now: Bill Gates or Steve Jobs?
Assembla has many powerful and hidden capabilities that can help you get your work done more efficiently. In order to get those most out of your Assembla projects, here are a few tips and tricks to help you and your team work smarter and faster. Do you have any tips and tricks you want to share Email firstname.lastname@example.org or tweet your tips with hashtag #AssemblaTips.
Get attention from your team members with @mentions. For extra certainty, add a ! at the end like @adam! or @support! to instantly send an email to that member or group.
Type @ and start typing a users name virtually anywhere in Assembla to call out users. User get notification alerts in their top bar to signify something needs their attention. Set up labels in the Team tab to mention groups like @support or @admin.
Focus the attention of your team by setting your project’s default landing page (tool) and arranging the tool tabs so that the most important tools are easy to find.
Visit the Admin tab of your project > click on the Appearance section > and scroll to the Navigation section. Drag and drop tools to rearrange the order of the tool tabs in the main navigation and select the desired default tool in the “default landing tab is” drop-down. When you have made the desired changed, scroll down and click on ‘Save Changes.’
Illustrate your point by dragging and dropping files on a ticket.
Once a ticket has been created, you can grab any file from your desktop and drop it anywhere on the ticket. This will upload and associate the dropped file to the ticket.
Edit ticket status values to create custom workflows. Additional status workflows will be displayed on the Cardwall view so you can visually see the status of all work in progress.
Go to the Tickets tool > Settings sub-tab > Status and Workflows section. You can create new statuses and rearrange the order of your statuses. The order the statuses appear on this page is the order they will appear in the status drop-down on tickets, and the order of the columns from left to right on your Cardwall view.
Get code reviews by setting repository branches as "protected” so only certain team members are able to push commits to a given branch after the code has been reviewed and approved.
Visit the repository’s tab within Assembla > Settings sub-tab > Protected Branches section and define what team members are allowed to perform what action to given branches.
If you do not have an Assembla project, get started for free.
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.