Skip to content

Feed aggregator

Squad Health Check model – visualizing what to improve

Henrik Kniberg's blog - Tue, 09/16/2014 - 10:00

Squad Health Check model

(Download the cards & instructions as PDF or PPTX)

At Spotify we’ve been experimenting a lot with various ways of visualizing the “health” of a squad, in order to help them improve and find systemic patterns across a tribe. Since a lot of people have been asking me about this, I wrote up an article about it together with coach-colleague Kristian Lindwall.

Read it on the Spotify labs blog: Squad Health Check model – visualizing what to improve.

Categories: Blogs

Sichtbarkeit ist der erste Schritt – das Taskboard auf Management-Ebene

Scrum 4 You - Tue, 09/16/2014 - 07:33

„Aber ich habe ja so viele Dinge, die ich jeden Tag erledigen muss – da kann ich doch gar nicht ständig einen Zettel schreiben?“ So oder so ähnlich lauteten in einem Projekt die Kommentare, als wir begannen, ein Taskboard auf Management-Level einzuführen. Ich kann das gut nachvollziehen, meine Taskliste von heute sieht so aus:

  • Kunde: Backlog mit N.N
  • Kunde: Meetings mit N.N. und O.O.
  • Kunde: Daily Scrum
  • Kunde: JIRA Training – Setup
  • Kunde: Arbeit an der Darstellung zur Meeting-Struktur
  • Marketing: Review Pressemitteilung Agile Bodensee
  • Blog: Brauchen wir noch Daily Standups?
  • Blog: Die Generation Y – “Wir wollen unser Leben genießen”
  • JIRA Playbook an alle geschickt
  • Travel: Flüge für die nächsten drei Wochen gebucht
  • Blog: Das Taskboard auf Management Ebene – Warum eigentlich ein Taskboard?
  • Intern: HR-Backlog und Unklarheiten besprochen
  • Sales: einen Kunden angerufen, und um Feedback gebeten
  • Travel: Ersatzreisedokument am Flughafen Berlin besorgt
  • Familie: Meine Frau vom Flughafen abholen

Soll ich da wirklich jedes Mal einen Zettel schreiben oder meine kleine 1h-Aufgabe in einem Tool wie JIRA oder Trello ablegen? Ihr könnt euch denken, dass ich vor mich hin schmunzle. Denn während ich das hier schreibe, habe ich ja gerade die Einträge für ein Taskboard erstellt. Das nun auf Klebezettel zu schreiben, oder vielleicht sogar in ein Tool wie JIRA einzutragen, ist sicher genauso möglich. Es ist ein wenig komplizierter, aber nicht sehr. Wer mehr dazu wissen will, wie man das effizient macht, dem sei Personal Kanban empfohlen. Und doch: Management-Teams wehren sich zunächst, diese wenigen Einträge zu machen. Also mache ich sie in meiner Rolle als ScrumMaster in der ersten Woche für das Management-Team. Auf diese Weise sehen sie auch, wie viele Dinge sie erledigt bekommen und wie viele Dinge sie abseits des Üblichen  noch so machen.

Ist Euch das auch schon mal aufgefallen? Die meisten Manager machen unendlich viele ad-hoc-Aufgaben, sie stecken zu tief im Tagesgeschäft. Ständige Störungen, permanente Meetings und sie werden von E-Mails überflutet. Konzeptionelles Arbeiten oder gar Führen ist fast nicht möglich. Ich habe schon öfter geschrieben, dass Henry Mintzberg das schon vor Jahren festgestellt hatte:

“Folklore: The manager is a reflective, systematic planner. The evidence of this issue is overwhelming, but not a shred of it supports this statement.

Fact: Study after study has shown that managers work at an unrelenting pace, that their activities are characterized by brevity, variety, and discontinuity, and that they are strongly oriented to action and dislike reflective activities. Consider this evidence: Half the activities engaged in by the five chief executives of my study lasted less than nine minutes, and only 10% exceeded one hour. A study of 56 U.S. foremen found that they averaged 583 activities per eight-hour shift, an average of 1 every 48 seconds. The work pace for both chief executives and foremen was unrelenting. The chief executives met a steady stream of callers and mail from the moment they arrived in the morning until they left in the evening. Coffee breaks and lunches were inevitably work related, and ever-present subordinates seemed to usurp any free moment.“

Trotzdem es ist etwas anderes, das täglich in der Praxis zu sehen. Management-Teams haben also nicht wirklich Zeit, das große Ganze zu sehen. Sie kommen gar nicht dazu, sich um die vielen wichtigen Aspekte zu kümmern, denn sie sind total beschäftigt. Gesehen haben wir ein ähnliches Phänomen in der Vergangenheit bereits bei skalierten Scrum-Implementierungen. Dort mit den Product Ownern konzeptionell zu arbeiten, in Ruhe ein Backlog aufzubauen, vielleicht zwei Tage intensiv daran arbeiten, eine wirklich ausgearbeitete Story Map zu erstellen – das war aufgrund der vielen Störungen gar nicht möglich. In diesen Kontexten hatten wir aber die Schwierigkeiten auf die Komplexität der Produkte geschoben.

Was mir jetzt als ScrumMaster eines Management-Teams auffällt: Es fehlt die Priorisierung. Alles scheint gleich wichtig, als wäre es in einem größeren Unternehmen nicht auch möglich, sich zu fokussieren. Gleichzeitig ist das nicht so viel anders als das, was die Arbeit von vielen Entwicklungsteams in der Vergangenheit gezeigt hat.

Wie kann ich meinem Management-Team dabei helfen: Mit einem Taskboard. Es macht transparent, wie viele Dinge erledigt werden müssen. Damit kann man daran arbeiten, die wirklich wichtigen Dinge zu tun und sich gegenseitig zu helfen. Jetzt brauche ich nur noch Geduld – wie bei allen Teams dauert es ein wenig, bis die Idee des Taskboards angenommen wird.

Literatur
Henry Mintzberg: The Manager’s Job: Folklore and Fact, HARVARD BUSINESS REVIEW: March/April 1990, p. 163 – 176

Related posts:

  1. 5 Minutes on Scrum | Transparency
  2. Prioritäten | Product Owners Tools
  3. Product Backlog | Templates | Scrum Tools

Categories: Blogs

Building a Change Artist

Agile Tools - Tue, 09/16/2014 - 06:45

Team

So you want your organization to change? Then you just might need a change artist. What is a change artist? A change artist is someone who leads change in an organization by sharing example and by influence using visualization. That is to say, a change artist will not mandate or coerce in order to introduce change, but rather they will begin with themselves and demonstrate their own change – thereby providing the example and the potential motivation for others to seek similar change in themselves. The visualizations help to share the story – you need the artist.

boulder

I think that people who are able to express their ideas through pictures are particularly well suited to creating the kinds of compelling visualizations that help convey what change might look like. They don’t have to be technically competent as an artist. Just good enough to draw stick figures and tell a story. Its really not that hard once you stop worrying about what people think.

Can we create people like this? Or are they born to it? I don’t think the hard part is the art. Anybody can do that. It’s how they approach change that matters most.

alligator

Perhaps there are organizations that would be more receptive to change initiatives that aggressively use visualization techniques. I can’t help imagine that visualization can add a compelling element to any transition engagement. I’ve not see much evidence of that sort of approach on agile transition engagements that I’ve been on. I’ve seen the power of what a simple drawing can do to draw people together and generate discussion. Using some sharpies and some butcher paper I can start a conversation that will continue long after I’m gone. I’ve seen it happen. There isn’t a text document in the world that can compete with a good picture. I’m not talking about Visio diagrams either. There is a quality to the hand drawn diagram that invites people to engage in a way that no sterile electronic diagram ever will. I’ve held two versions of the same diagram, one hand drawn and one electronic, side by side and the preference is almost always unanimous – the hand drawn version wins. I think the magic lies somewhere in the the errors and mistakes in the drawing. They must serve to remind us that we are  human. Perfection isn’t necessary, and in fact may be counterproductive.

That’s who I want to help me change the world. Combine the passion for change and the art and I’ll give you a change artist.

periodic


Filed under: Agile, Coaching Tagged: Agile, artist, change, change artist, Transition
Categories: Blogs

How to Run Effective Standups and Retrospectives

Step three of The Kanban Roadmap: How to Get Started in 5 Steps As a systems-thinking methodology, Kanban calls for team members to take collective responsibility for team priorities. Rich conversations about the work are a must-have. They help the team discover bottlenecks, resolve issues, focus on flow, and continuously improve their process. To facilitate […]

The post How to Run Effective Standups and Retrospectives appeared first on Blog | LeanKit.

Categories: Companies

An Agile Journey Through Japan

Danube - Mon, 09/15/2014 - 19:18

Agile Development vs. Enterprise Agility in Japan’s Embedded Software Development

This week I happened to reread an article sent to me by André Girard, a Senior Analyst at VDC Research.  Interestingly, I read in on my way from Tokyo to Bangalore after a week of great meetings in Japan visiting prospects, partners and clients.  I was also in Japan to launch a major partnership in Japan with Hitachi Solutions to provide joint offerings in the DevOps IT market, as well as the embedded SW development space.  For those of you who are better than me at Japanese, take a look at the bottom of this article at some of the press we received within 8 hours of announcing this partnership on September 12th.

Andre and VDC specialize in analyzing advancements and trends in embedded software development.  In Andre’s article he sent to me, I repeatedly saw reinforcement of several of the points he made in a dozen+ meetings over 6 days:

-          Increasing interest in agile overall – at all levels of the company

-          A need to codify agile processes with tools to build repeatable processes

-          A need to have an adaptive, learning and scaling set of tools and processes

However, one difference that I saw in Japan is that agile development, although being widely adopted, is still being driven bottom up. In sharp contrast, in Europe and the US, agile and more importantly “business agility” has almost become an executive strategic imperative.   Towards that end and to strong interest, CollabNet recently codified our 15 years of experience in helping companies transform from distributed and isolated to agile, collaborative and leveraged into a straightforward and practical “Blueprint for Enterprise Agility”, based on the open and adaptive CollabNet TeamForge platform.

This Blueprint for business agility was quite an eye opener for the clients and prospects we met with in Japan.  The reason is that executive awareness and focus on overall enterprise agility is not yet the case in many traditional companies in Japan, where senior management is still struggling with their more structured ways of working across an organization.  CollabNet’s partnership with Hitachi is geared at accelerating this IT and embedded SW development transformation in Japan from developer driven agile development activities to executive results focused business agility.

On a positive side, I did see this executive awareness of the need for organizational wide agility in some of the younger Japanese companies.  If the press and strong reception we received at multiple large companies is any indication, the market in Japan may be waking up to what we are already seeing in other parts of the world.

Also, be sure to join me Thursday September 17th for a webinar on How To Scale Application Development & Delivery Across the Enterprise.  You can register here.

Bill

PS.  And for those fluent in Japanese, or just want to look at the pictures, read on!

http://cloud.watch.impress.co.jp/docs/news/20140912_666586.html

http://itpro.nikkeibp.co.jp/atcl/news/14/091200867/

http://codezine.jp/article/detail/8113

http://www.excite.co.jp/News/column_g/20140912/Cobs_042028.html

http://enterprisezine.jp/article/detail/6150

http://headlines.yahoo.co.jp/hl?a=20140912-00000105-impress-sci

http://sankei.jp.msn.com/economy/news/140912/prl14091216020133-n1.htm

The post An Agile Journey Through Japan appeared first on blogs.collab.net.

Categories: Companies

The Product Owner Role in Sprint Retrospective

Scrum Expert - Mon, 09/15/2014 - 18:03
The sprint retrospective in an important moment in the Scrum approach where the team think about its software development process and tries to improve it. As on of the three Scrum roles, the product owner has to play its part in this activity. In this blog post, Roman Pichler explains how product owner can play an active role during the retrospective meetings. The sprint retrospective meetings takes place at the end of the sprint after the sprint review meeting and should produce improvement measures. The product owner has to take ...
Categories: Communities

Microsoft Announces Team Foundation Server Support for SAFe

Agile Product Owner - Mon, 09/15/2014 - 17:01

SAFe relies on transparency and objective metrics to measure and improve software development outcomes. And as we work exclusively at scale, tooling is, of course, required. Last week, Microsoft announced their support for SAFe in Team Foundation Server. As you can see in that post, TFS provides an at-a-glance interface that provides team metrics, measures capacity, and visually tracks progress in the context of SAFe best practices. InCycle’s Barry Paquet (a Scaled Agile Partner) provides a further description of how TFS and SAFe can be used at the team and program level:

“For example, at the program or feature level, we measure progress against what we have accepted or observed (think sprint review and system demo). Moreover, we can report against planned features and percent (%) complete. Given that TFS doesn’t provide this report OOTB, the team at InCycle developed a TFS report to illustrate what’s possible and demonstrate how TFS can be used to support scaled agile or SAFe. Below is a sample report we created to support our SAFe customers.”

Example of Incycle's TFS Report

Example of Incycle’s TFS Report

You can read more about TFS and SAFe on Barry’s blog entry, “Scaling Agile and SAFe Metrics with TFS,” and read Microsoft’s post here. Thanks to Barry Paquet, Incycle Director, ALM Practice (West Region), for his contributions, and to the folks at Microsoft who authored this report, especially Gregg Boer, SPC, and the product owner for the Agile Management experience in TFS.

Stay SAFe,
–Dean

Categories: Blogs

Agile @ Scale (slides from Sony Mobile tech talk)

Henrik Kniberg's blog - Mon, 09/15/2014 - 14:09

Here are the slides from my tech talk Agile @ Scale at Sony Mobile. Full house & very high level of engagement, I was impressed by this crowd! And thanks for the awesome recommendation on LinkedIn :)

 

Some sample pics below:

Visualize and limit WIP

Visual planning

Productivity and motivation

 

Tradeoffs

Categories: Blogs

Kanban Canvas InfoQ Interview

AvailAgility - Karl Scotland - Mon, 09/15/2014 - 14:08

Last week InfoQ published an interview that I gave with Katherine Kirk at Agile2014 in which we talked about the Kanban Canvas, why I came up with it, and how I use it. Unfortunately I can’t embed it here, so please use the following link to find it:

Karl Scotland introduces the Kanban Canvas.

Categories: Blogs

Getting Starting on #POcampCH -- the Product Owner Camp Switzerland

Scrum Breakfast - Mon, 09/15/2014 - 12:33
Today, the organization team for the first Product Owner Camp in Switzerland, held its first telco. Here is what we decided:
  1. Our target date is March 2015, the alternative is June, 2015.
  2. The open space will be held on a Friday and Saturday.
  3. We want to hold a Product Owner Masterclass, one or two days before the Open Space event.
  4. The audience is experienced Product Owners, Agile Product Managers and Lean Startup Practitioners. This is by practitioners for practitioners, not for beginners.
  5. The event is not profit oriented. 
  6. We are going to get together on skype roughly once every to two weeks to take the event forward. 
We are thinking hotel in the mountains, we will start exploring possibilities once the constraints for the workshop are defined. 
We have created a backlog to organize our work: Our first objective is the find a leader for the MasterClass, reserve some dates, and start working on the website. After that, priority will be the venue...

Several other people expressed an interest in helping to organize, we will welcome them as they confirm their participation :-)!
Are you interested in participating (or even helping out?) Join our google group to stay informed!
Categories: Blogs

Increase speed by incentives and sacrifice quality

Agile World - Venkatesh Krishnamurthy - Mon, 09/15/2014 - 12:29

Recently  I read an article in the news paper about improving the speed of passport delivery to citizens.  This is the news published in Times of India. It seems that passports are getting delayed as the police verification is taking a lot of time. In order to improve the speed, the passport office is planning to incentivize the police.  That is, if  the police completes their verification within 21 days, then would get more money else they are penalized by reducing the incentive.  I felt that this is one of the most dumbest idea ever implemented !!

Here is the quote from the news paper:

However, he said the delivery of passports has been expedited by incentivizing police. "We have reduced the time taken for delivery once the application is sent for processing. We are insisting that the police department send in police verification reports in 21 days. For each report sent before 21 days, cops are incentivized Rs 150 per report. If sent later, they get Rs 25 only. This will reduce the time taken to get the passport delivered. In some cases, the passport is delivered less than a week if verification report is sent fast,"

There are couple of issues with the above idea:

1. I don’t think any root cause analysis has been done to identify the delay in verification. There could be various reasons for the delay.

      For example, this passport verification may not be the top of police’s backlog list.  It is also possible that police force don’t have sufficient people to support this activity.

A root cause analysis could have helped to unearth the real cause of the delay and proper action could have been taken.

2. Going forward, I could see that the all police verification will complete within 21 days due to incentives. Question is, at the cost of  WHAT ?    I could see that the quality of verification will drop heavily as the possible root causes are never addressed. 

Being in the software industry, we keep hearing that external motivation causes more harm than the anything else.  The above story correlates to what we commonly see in the organizations. Employees are incentivized for ensuring on time delivery. But the companies pays for the cost of quality at a later stage, which no one really bothers or accounts for. 

Categories: Blogs

How much do you let a new team self organize?

Scrum Breakfast - Mon, 09/15/2014 - 09:00

I have a team of 11 developers and 3 Product Owners. Their ideas about how to organize the team are all over the place. Some want to do 1 week sprints. Others want one month sprints. And we pull in resources people so we can get the right velocity to meet our deadlines. This seems like a mess. How much should I let my beginning team self-organize? -- recently asked on a Scrum Discussion Forum.    Modifying a complex technique before you have mastered it is a failure pattern. So when you are just getting started, try to get as close to Scrum by the book as you can, without obsessing over it... much. I call this Pretty Good Scrum(tm). ;-)

Yes the team self-organizes... and the Scrum Master is charged with teaching the team and helping them improve. When the team is just getting started, it should follow the lead the of Scrum Master, and the Scrum Master should stay close to the book. As they get better, they'll be better able to inspect and adapt themselves.

Successful teams learn quickly. How do you learn quickly? Short answer: Do short sprints. More in a moment.

Remember, never hit anyone with the book! The rules of Scrum are there to help you, not to threaten or punish people. Be sure you can answer why the rule of Scrum is a good answer. Treat everything as an experiment or learning exercise, so they have the security of knowing they can change things later. That's what retrospectives are for.

It will probably take you three or four sprints to get to Pretty Good Scrum. That's why I recommend one week sprints to start. Why learn in four months what you can learn in 4 weeks?

If I were confronted with the situation above, I would ask five questions and help the team(s) and PO(s) find answers that stay within the constraints defined by Scrum.

1. How big is a Scrum team? 7+/-2. To stay in those bounds, you need two teams. Ask your teams how they want divide themselves, respecting that constraint. By giving them the problem, they become responsible for the solution, so they won't come to you anymore with "yes, but..."! If they talk about limited specialists, ask them how to resolve the problem.

2. How many Product Owners does a Scrum Team have? One, though you might also have a Chief Product Owner role in the case of multiple teams. Ask your product owners how they want to split up their work. And yes, the PO is responsible for the Vision. Do they have one, can they communicate it? Is it shared and supported by the Team and other stakeholders?

3. How long is the Sprint? Normally this is negotiated between PO and Team. And... as Scrum Master you are responsible for the process, which gives you the right to intervene to improve the team. Shorter sprints accelerate learning. So I would suggest starting with a couple of one week sprints. Be sure to get your team to agree to this. I have also had great experiences doing 2 or 3 sprints at 59 minutes each (ask me more about this if you're interested).

4. Who estimates and decides how much work can be accomplished in a sprint? The team. Not the math, not the PO, not the stakeholders and not management. Have them estimate the work, and don't let them take on more than they can chew. Think of highways at rush hour if you want to know why this is a good idea.

5. Whose job is it to make sure that wish and reality are in harmony with each other? The Product Owner. If the desired scope does not match up with the team's reasonable forecast of what they can accomplish by the desired release date (aka deadline), whose job is it to fix the problem? The PO. Given your context, conversations about reducing scope and the impact of product-level multitasking on ROI might be quite fruitful!

Back to the original question: "How much do you let a new team self organize?" The answer is "quite a lot!" The trick is setting constraints that cause people to come up with right answers.
Categories: Blogs

“Du nervst!” – Wie man mit Menschen umgeht, die einen in den Wahnsinn treiben

Scrum 4 You - Mon, 09/15/2014 - 07:45

Es gibt sie immer – Menschen, mit denen man nicht gut klarkommt. Seien es Kollegen, Kunden, Berater, Bekannte innerhalb des eigenen Freundeskreises und des öfteren sogar Familienmitglieder. Sie alle sind Teil unterschiedlicher Systeme, in denen man sich bewegt. Jedes Mal, wenn ich eine jener Personen antreffe, merke ich sofort, wie mein Blutdruck ansteigt und ich mich bemühen muss, freundlich und geduldig zu bleiben. Nach jahrelanger Beratertätigkeit, bei der ich schon die unterschiedlichsten Menschentypen angetroffen habe, meine ich nun, ein paar Möglichkeiten gefunden zu haben, um in der Anwesenheit eines (für mich) nervigen Menschen einen kühlen Kopf zu bewahren. Hier meine fünf persönlichen Favourites:

  1. Durch Beobachtung herausfinden, was es ist, das mich nervt. Sei es eine gemeinsame Historie, Handbewegungen, Dialekt, Körperhaltung etc. Egal – der Fantasie sind hier keine Grenzen gesetzt. Dann sollte man sich selbst fragen, weshalb diese Aspekte einen nerven. Es könnte ja sein, dass man Opfer des Resonanzgesetzes geworden ist.
  2. Positives Hinterfragen. Was schätzen gemeinsame Bekannte an dieser Person? Welche Aspekte würden dir fehlen, wenn diese Person nicht mehr da wäre? Was müsstest du an Rollen in eurem System übernehmen? Würden Aufgaben auf dich übergehen? Man kann sich auch absurde Fragen stellen wie: „Wenn ich mich in diese Person verlieben müsste, welche Aspekte wären es, die mich anziehen würden?“
  3. Man könnte versuchen, eine Veränderung im Verhalten der anderen Person herbeizuführen. Dies kann man erreichen, indem man positives Verhalten durch Feedback hervorhebt und bestärkt. Meine Erfahrung ist, dass kontinuierliches Feedback über einen längeren Zeitraum einen wirklichen Unterschied macht.
  4. Offenlegen. Wie wichtig dieser Aspekt ist, hat mich meine Coachingausbildung gelehrt. Hier ist essenziell, dass man ehrlich ist und beim Feedback bei sich selbst anfängt. Richtig wäre „Liebe Caro, ich habe manchmal das Gefühl, dass wir an einander vorbeireden. Oder “Liebe Caro, manchmal scheint es mir, als würden jene Punkte, die ich anmerke, bei dir nicht das Gehör bekommen, das sie meines Erachtens nach bekommen sollten.“ Zu vermeiden sind Floskeln wie „Das ist so“ oder Worte wie „immer“. Denn das stimmt ja nicht – erstens gibt es immer Ausnahmen und zweitens ist es eine persönliche Meinung. Hier ist es auch wichtig, auf die Kultur zu achten – während man in Österreich eher von der Maschekseite kommen würde, geht es in Deutschland zum Beispiel direkter zu.
  5. Nach der Offenlegung die Meinung des Gegenübers abholen: „Siehst du das genauso?“ Und anschließend “was können wir tun, um die aktuelle Situation zu verändern?”

Falls keiner der genannten Punkte funktioniert, würde ich empfehlen, einen Systemischen Business Coach aufzusuchen und das Thema mit ihm durchzuackern.

Mit welcher der fünf Optionen hast du schon Erfahrungen gesammelt? Welchen sechsten Tipp würdest du mir raten, in mein Repertoire aufzunehmen?

Related posts:

  1. Bin ich am Arbeitsplatz zufrieden?
  2. Erinnerung: Scrum Breakfast diesen Samstag im Quadro!
  3. Feedback geben können oder warum auch ein alter Hut gut aussehen kann

Categories: Blogs

The Release Paradox: releasing less often makes your teams slower and decreases quality

Software Development Today - Vasco Duarte - Mon, 09/15/2014 - 05:00

Herman is a typical agile coach. He works with teams to help them learn how to deliver high-quality software quickly.
Many teams want to focus on design, architecture, or (sometimes) even on business value. But they are usually not in a hurry to release quickly.
Recently Herman conveyed a story to me that illustrates how releasing quickly can help teams deliver high-quality software much faster than if they would focus on quality in the first place. This is the case of a team that was working on a long overdue project. They had used a traditional and linear process in the past and had been able to release software only very recently, after more than 12 months of work on the latest release.
Not surprisingly, they were having trouble releasing regularly. The software was not stable; once it was live it had many problems that needed to be fixed quickly, and worst of all: all of this was having a direct impact on the company’s business.
The teams were extremely busy fixing the problems they had added to the product in the last year and could not focus on solving the root causes of those problems.
They were in full-fledged firefighting mode. They worked hard every day to fix yet another problem and release yet another hot fix.
This lasted for a few weeks, but once the fire-fighting mode was over, Herman worked with the teams to improve their release frequency. During their work with Herman, those teams went from one year without any release to a regular release every two weeks.
At first the releases were not always possible, but with time they improve their processes, removed the obstacles preventing them from releasing every two weeks and started releasing regularly.
What happened next was surprising for the teams. The list of problems after each release did not grow - as they expected - but instead shrank.
When some problems came in from the customers after a 2-week release, they were also much faster to fix the problem and quicker to release a fix if that was required. When the fix was not critical, they waited for the following release which was, after all, only 2 weeks away.
By focusing on releasing every two weeks, Herman’s teams were able to focus on small, incremental changes to their product. That, in turn, enabled them to fine-tune their development and release processes.
Here are some of the key changes the teams implemented
  1. They started with a 4 week release cycle, and fine-tuned their daily builds and release testing process to enable a release every 2 weeks.
  2. They invested time and energy to improve their test automation strategy and automated the critical tests to enable them to run “enough” tests to be confident that the quality was at release level.
  3. They had some teams on maintenance duty in the first few iterations to make sure that any problem found after release could quickly be fixed, and released to customers if necessary.
  4. They changed their source code management strategy to enable some teams to work on longer term changes while others worked on the next release.
  5. They involved all teams necessary to complete a release in their iterations. This affected especially: production/operations team, localization team, documentation team, marketing team, and other teams when needed.
This list of changes was the result of the drive to complete each release and learning from the failures in the previous release. Some changes were harder to implement, and especially the testing strategy to allow for 2-week release cycles had to be changed and adjusted several times.
One of the key problems the teams had to solve, was the lack of coordination with departments that directly contributed to the release but were not previously involved in their day-to-day work.
This process lasted several months, and would not have been possible without a clear Vision set forth by the teams in cooperation with Herman, who helped them discover the right way to reach that Vision within their context.
Herman’s work as a coach was that of a catalyst for management and the teams in that organization. He was able to create in their minds a clear picture of what was possible. Once that was clear, the teams and the management took ownership of the process and achieved a step-change in their ability to fulfill market demands and customer needs.
Customers have no reason to change provider as they have an ever-improving experience when using this company’s services.
Today, this organization releases a new version of their product every two weeks. Unaware of it, their customers receive regular improvements to the product they use, and have no reason to change provider as they have an ever-improving experience when using this company’s services.

Picture credit: John Hammink, follow him on twitter

Categories: Blogs

Agile Ottawa – September Event – Announcement and Links

Agile Ottawa - Sun, 09/14/2014 - 22:20
Thanks to Phil Green (twitter: @pg5150) for his engaging workshop on “User Story Mapping” this week.  Thank you also to all who came out and participated in the event… we had a packed house and a great time. As promised, here are some … Continue reading →
Categories: Communities

Hierarchy vs. Constellation

Agile Tools - Sun, 09/14/2014 - 21:14

SONY DSC

“Organizations must shift away from repetitive-function hierarchies with rules and enforcement and walls. Instead, we must migrate rapidly to becoming a global ‘team of teams’ that comes together in whatever combination necessary to add the greatest value to the changes underway.” – Bill Drayton

It’s easy to despair that people can not see social structures as anything other than dominance hierarchies. I suppose that makes sense given our primate origins. In college, I spent hundreds of hours observing chimpanzees at the local zoo as part of a research project. It doesn’t take very long to understand the hierarchy within a small colony of apes. The dominant ape spends a significant portion of this time strutting around making sure everyone knows he’s the boss. He uses every tool in the book, from the brutish power of dominance displays, all the way to the subtle selection of who gets to groom him first. He’s the big man on top.

However, the longer you watch, the more you start to detect other hierarchies within the primate social system. Female chimps have their own sub hierarchy that is just as much a power game as that of the dominant male. Within a very short time you are seeing different types of social hierarchy all over the place. I found myself in awe of the number and complexity of the hierarchies that chimpanzees display. I would maintain that the hierarchies and power games played by chimps rivals anything we have in even the most vicious office politics.

Of course, maybe the hierarchy is in the eye of the beholder. Perhaps we humans are wired to categorize things according to certain patterns. Maybe we are just inclined to see everything in terms of hierarchies as some sort of side effect of the way our perceptual systems are set up. I imagine there is some of that at work here. After all, as primates we have been fine tuning our hierarchical behavior for millennia, so it would be no surprise if we tend to see them everywhere we look.

That notion, that hierarchy is a sort of built in default, is a pretty depressing idea if, like me, you aren’t all that fond of hierarchies. There is no doubt that hierarchies have their advantages, but they have disadvantages too. Look how well the hierarchy has worked out for the Chimpanzees. They are well on their way toward extinction, so you could argue that whatever social strategy they are using, it’s not contributing sufficiently to help ensure their survival.

“Male chimpanzees have an extraordinarily strong drive for dominance. They’re constantly jockeying for position.” – Frans de Waal

It may be that because the chimpanzee is so geared toward hierarchy they are unable to utilize other social structures that would allow them to adapt to their changing environment. Perhaps it is their inability to change their behavior that spells their doom. On the one hand, blame the human for killing them. On the other, recognize that this is an adaptive challenge to which the chimpanzee has not found a winning strategy to counter.

Fortunately, humans appear to be capable of a bit more flexibility when it comes to our social and organizational structure. That is, while we still lean strongly toward the hierarchy (call it the default if you will), we seem to be capable of using other ways of organizing ourselves when the need arises.

That’s a good thing, because whether you are a business, or a society, we face a number of challenges as well. Recently a friend introduced me to Ashby’s Law of Requisite Variety,

If a system is to be stable the number of states of its control mechanism must be greater than or equal to the number of states in the system being controlled. Ashby states the Law as “variety can destroy variety”

In a nutshell, when a system faces a challenge, the complexity of that system must be equal to the complexity of the threat in order for the challenged system to survive. Let’s take that back to hierarchy now. Hierarchies consolidate decision making and rely on decisions made by the guy at the top. This helps to simplify the number of responses, which can be useful, but may not be the most adaptive strategy when under threat. In a complex environment, a hierarchy is a rather simplistic structure to use. It doesn’t have the requisite variety required to cope with a complex environment where challenges can arise in many different forms. fortunately, nature has provided us with many different models of social organization to choose from.

In a peer network, no one is officially in charge. It doesn’t have a command hierarchy. It doesn’t have a boss. So, all the decisions are somehow made collectively. The control of the system is in the hands of everyone who is a part of it. – Steven Johnson

Take insects, for example, they use a very different structure often described as a swarm. The swarm does not rely on a single individual or a subset of individuals to determine its response to a given challenge. This means that the swarm can use all of the members of its population to dynamically respond to a challenge. This leads to combinatorial explosion of different alternatives, which gives the swarm a huge arsenal of complex responses. It’s probably worth noting that on an evolutionary scale, the insects have been pretty successful using this strategy (and there are those who would argue they are the most likely to win).

Of course people can use these strategies too. Swarming and other social models are much more rarely used by people, but there are examples. Wikipedia is a great example of a swarm where there is no top down direction. Some organizations, like AA are also good examples. While there are not a lot of examples to choose from, with the increasing complexity of our social and business environments one might wonder if we may see an increasing diversity of swarms and other alternative social structures as a result.

Time will tell. I think the recent evolution of various and sundry Agile methods may be a hint that the underlying social structures are broken, and that people see a need for alternative structures to hierarchy in order to meet the challenges of today’s ever more complex challenges. If that is the case, then I expect to see many more of these Agile methods and frameworks arising in the not too distant future.


Filed under: Agile, Process, Swarming, Teams Tagged: Ashby, Behavior, chimpanzees, constellation, dominance, hierarchy, power, swarm, Swarming, variability, variety
Categories: Blogs

Starting Backwards

Agile Tools - Sun, 09/14/2014 - 08:11

dangerous-fast-force-2438-466x350

If you were to draw a diagram of the entire product development process from start to finish, what would you start with? If you are like me, you’d probably start with the customer, or maybe sales. Then you’d probably pass the idea along to product management and onward to development. Last, but not least, the product would make its way to operations for deployment in production.

It’s pretty straightforward, front to back, end-to-end. Everybody knows how it works. And if we are going to try to improve this process, where do you think we typically start?

At the front? In sales? No.

At the back? With operations? No. Not there either.

Right smack dab in the middle? BINGO! Development always gets the love first.

Now what kind of lunacy is that? Now I’ve been part of a process improvement effort or two, so naturally I start to think I see patterns. Well, hallucinations of some kind anyway. Almost every time we start with the development teams. We do a good job, we get them up and sprinting, train a few scrum masters, console a few managers, and Bob’s your uncle: the dev teams are agile! Then what happens?

Downstream, the operations teams aren’t on board with the whole agile thing. They aren’t going to let you change their release processes just to satisfy some fad. Rapid change? Are you nuts? And what about the other end of the value stream, sales? They’re willing enough if it makes them money, but you’d better deliver (which isn’t happening with the operations guys, so you are screwed).

So lets take a step back and look at the value stream. Where do we typically see the most time spent? It’s not development – we’ve been squeezing development in one way or another for decades. However, you can find the most amazing queues in sales. With the rest of the organization moving so slowly, they naturally develop queues as they wait for the work to get done.

The question is, why don’t we start at the back? Why don’t we make the end of the value stream our focus first? We need to stop starting in the middle. Goldratt would have us chasing the bottlenecks. More power to him. If I speed up operations first, I may not see an immediate increase in productivity, but I have created the runway for success. I have them on board and bought in. Now, we move up the value stream to the Development teams. If we can get them performing, then we have already prepared the runway for them. No longer do we give them a fast car and ask them to drive it into the wall. Now they can deliver and they can do it with proper support from operations.

From there we can continue to move up to Sales and the front end of the value stream. They should be an easy sell at this point. So, the question is, why start in the middle?


Filed under: Agile, Coaching, Process, Teams Tagged: Agile, Process, Transition, value stream
Categories: Blogs

Your understanding of Kaizen is wrong

Agile World - Venkatesh Krishnamurthy - Sun, 09/14/2014 - 06:59

Kaizen is popularly associated with continuous learning or continuous improvement.  However, where people get wrong is who should continuously improve ? 

Most Agilists and Leanists use Kaizen in the context of team improvement. That is, an agile team should continuously improve, and thus excluding the managers/leaders, rest of the company. 

This is exactly where the understanding goes wrong.   The true Kaizen involves continuous improvement across the organization starting from the CxOs, and involving HR department, Finance, PMOs, Sales and marketing. It is also about improving everyday and everywhere. 

So to conclude, you are not really following Kaizen if the expectation for improvement is only for the team(shopfloor) and rest are excluded !!!

Watch this video to hear directly from the master Masaaki Imai, founder of Kaizen Institute

https://www.youtube.com/watch?v=jRdTFis4-3Q

image

Categories: Blogs

Agile Games at Agile Open Southern California

Agile Learning Labs - Sun, 09/14/2014 - 04:55

Our very own Laura Powers recently participated in Agile Open Southern California, where she was interviewed by Scott Dunn. Laura talks about the power of games to help executives understand the changes they need to make in order for their organizations to become more agile.

The video was put together by Cliff Rosa of Rosa Media Productions.

Categories: Companies

iOS Today Widget in Swift - Tutorial

Xebia Blog - Sat, 09/13/2014 - 19:51

Since both the new app extensions of iOS 8 and Swift are both fairly new, I created a sample app that demonstrates how a simple Today extension can be made for iOS 8 in Swift. This widget will show the latest blog posts of the Xebia Blog within the today view of the notification center.

The source code of the app is available on GitHub. The app is not available on the App Store because it's an example app, though it might be quite useful for anyone following this Blog.

In this tutorial, I'll go through the following steps:

New Xcode project

Even though an extension for iOS 8 is a separate binary than an app, it's not possible to create an extension without an app. That makes it unfortunately impossible to create stand alone widgets, which this sample would be since it's only purpose is to show the latest posts in the Today view. So we create a new project in Xcode and implement a very simple view. The only thing the app will do for now is tell the user to swipe down from the top of the screen to add the widget.

iOS Simulator Screen Shot 11 Sep 2014 23.13.21

Time to add our extension target. From the File menu we choose New > Target... and from the Application Extension choose Today Extension.

Screen Shot 2014-09-11 at 23.20.34

We'll name our target XebiaBlogRSSWidget and of course use Swift as Language.

XebiaBlogRSS

The created target will have the following files:

      • TodayViewController.swift
      • MainInterface.storyboard
      • Info.plist

Since we'll be using a storyboard approach, we're fine with this setup. If however we wanted to create the view of the widget programatically we would delete the storyboard and replace the NSExtensionMainStoryboard key in the Info.plist with NSExtensionPrincipalClass and TodayViewController as it's value. Since (at the time of this writing) Xcode cannot find Swift classes as extension principal classes, we also would have to add the following line to our TodayViewController:

@objc (TodayViewController)
Add dependencies with cocoapods

The widget will get the latest blog posts from the RSS feed of the blog: http://blog.xebia.com/feed/. That means we need something that can read and parse this feed. A search on RSS at Cocoapods gives us the BlockRSSParser as first result. Seems to do exactly what we want, so we don't need to look any further and create our Podfile with the following contents:

platform :ios, "8.0"

target "XebiaBlog" do

end

target "XebiaBlogRSSWidget" do
pod 'BlockRSSParser', '~> 2.1'
end

It's important to only add the dependency to the XebiaBlogRSSWidget target since Xcode will build two binaries, one for the app itself and a separate one for the widget. If we would add the dependency to all targets it would be included in both binaries and thus increasing the total download size for our app. Always only add the necessary dependencies to both your app target and widget target(s).

Note: Cocoapods or Xcode might give you problems when you have a target without any Pod dependencies. In that case you may add a dependency to your main target and run pod install, after which you might be able to delete it again.

The BlockRSSParser is written in objective-c, which means we need to add an objective-c bridging header in order to use it from Swift. We add the file XebiaBlogRSSWidget-Bridging-Header.h to our target and add the import.

#import "RSSParser.h"

We also have to tell the Swift compiler about it in our build settings:

Screen Shot 2014-09-12 at 15.35.21

Load RSS feed

Finally time to do some coding. The generated TodayViewController has a function called widgetPerformUpdateWithCompletionHandler. This function gets called every once in awhile to ask for new data. It also gets called right after viewDidLoad when the widget is displayed. The function has a completion handler as parameter, which we need to call when we're done loading data. A completion handler is used instead of a return function so we can load our feed asynchronously.

In objective-c we would write the following code to load our feed:

[RSSParser parseRSSFeedForRequest:[NSURLRequest requestWithURL:[NSURL URLWithString:@"http://blog.xebia.com/feed/"]] success:^(NSArray *feedItems) {
  // success
} failure:^(NSError *error) {
  // failure
}];

In Swift this looks slightly different. Here the the complete implementation of widgetPerformUpdateWithCompletionHandler:

func widgetPerformUpdateWithCompletionHandler(completionHandler: ((NCUpdateResult) -> Void)!) {
  let url = NSURL(string: "http://blog.xebia.com/feed/")
  let req = NSURLRequest(URL: url)

  RSSParser.parseRSSFeedForRequest(req,
    success: { feedItems in
      self.items = feedItems as? [RSSItem]
      completionHandler(.NewData)
    },
    failure: { error in
      println(error)
      completionHandler(.Failed)
  })
}

We assign the result to a new optional variable of type RSSItem array:

var items : [RSSItem]?

The completion handler gets called with either NCUpdateResult.NewData if the call was successful or NCUpdateResult.Failed when the call failed. A third option is NCUpdateResult.NoData which is used to indicate that there is no new data. We'll get to that later in this post when we cache our data.

Show items in a table view

Now that we have fetched our items from the RSS feed, we can display them in a table view. We replace our normal View Controller with a Table View Controller in our Storyboard and change the superclass of TodayViewController and add three labels to the prototype cell. No different than in iOS 7 so I won't go into too much detail here (the complete project is on GitHub).

We also create a new Swift class for our custom Table View Cell subclass and create outlets for our 3 labels.

import UIKit

class RSSItemTableViewCell: UITableViewCell {

    @IBOutlet weak var titleLabel: UILabel!
    @IBOutlet weak var authorLabel: UILabel!
    @IBOutlet weak var dateLabel: UILabel!

}

Now we can implement our Table View Data Source functions.

override func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
  if let items = items {
    return items.count
  }
  return 0
}

Since items is an optional, we use Optional Binding to check that it's not nil and then assign it to a temporary non optional variable: let items. It's fine to give the temporary variable the same name as the class variable.

override func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
  let cell = tableView.dequeueReusableCellWithIdentifier("RSSItem", forIndexPath: indexPath) as RSSItemTableViewCell

  if let item = items?[indexPath.row] {
    cell.titleLabel.text = item.title
    cell.authorLabel.text = item.author
    cell.dateLabel.text = dateFormatter.stringFromDate(item.pubDate)
  }

  return cell
}

In our storyboard we've set the type of the prototype cell to our custom class RSSItemTableViewCell and used RSSItem as identifier so here we can dequeue a cell as a RSSItemTableViewCell without being afraid it would be nil. We then use Optional Binding to get the item at our row index. We could also use forced unwrapping since we know for sure that items is not nil here:

let item = items![indexPath.row]

But the optional binding makes our code saver and prevents any future crash in case our code would change.

We also need to create the date formatter that we use above to format the publication dates in the cells:

let dateFormatter : NSDateFormatter = {
        let formatter = NSDateFormatter()
        formatter.dateStyle = .ShortStyle
        return formatter
    }()

Here we use a closure to create the date formatter and to initialise it with our preferred date style. The return value of the closure will then be assigned to the property.

Preferred content size

To make sure we that we can actually see the table view we need to set the preferred content size of the widget. We'll add a new function to our class that does this.

func updatePreferredContentSize() {
  preferredContentSize = CGSizeMake(CGFloat(0), CGFloat(tableView(tableView, numberOfRowsInSection: 0)) * CGFloat(tableView.rowHeight) + tableView.sectionFooterHeight)
}

Since the widgets all have a fixed width, we can simply specify 0 for the width. The height is calculated by multiplying the number of rows with the height of the rows. Since this will set the preferred height greater than the maximum allowed height of a Today widget it will automatically shrink. We also add the sectionFooterHeight to our calculation, which is 0 for now but we'll add a footer later on.

When the preferred content size of a widget changes it will animate the resizing of the widget. To have the table view nicely animating along this transition, we add the following function to our class which gets called automatically:

override func viewWillTransitionToSize(size: CGSize, withTransitionCoordinator coordinator: UIViewControllerTransitionCoordinator) {
  coordinator.animateAlongsideTransition({ context in
    self.tableView.frame = CGRectMake(0, 0, size.width, size.height)
  }, completion: nil)
}

Here we simply set the size of the table view to the size of the widget, which is the first parameter.

Of course we still need to call our update method as well as reloadData on our tableView. So we add these two calls to our success closure when we load the items from the feed

success: { feedItems in
  self.items = feedItems as? [RSSItem]
  
  self.tableView.reloadData()
  self.updatePreferredContentSize()

  completionHandler(.NewData)
},

Let's run our widget:

Screen Shot 2014-09-09 at 13.12.50

It works, but we can make it look better. Table views by default have a white background color and black text color and that's no different within a Today widget. We'd like to match the style with the standard iOS Today widget so we give the table view a clear background and make the text of the labels white. Unfortunately that does make our labels practically invisible since the storyboard editor in Xcode will still show a white background for views that have a clear background color.

If we run again, we get a much better looking result:

Screen Shot 2014-09-09 at 13.20.05

Open post in Safari

To open a Blog post in Safari when tapping on an item we need to implement the tableView:didSelectRowAtIndexPath: function. In a normal app we would then use the openURL: method of UIApplication. But that's not available within a Today extension. Instead we need to use the openURL:completionHandler: method of NSExtensionContext. We can retrieve this context through the extensionContext property of our View Controller.

override func tableView(tableView: UITableView, didSelectRowAtIndexPath indexPath: NSIndexPath) {
  if let item = items?[indexPath.row] {
    if let context = extensionContext {
      context.openURL(item.link, completionHandler: nil)
    }
  }
}
More and Less buttons

Right now our widget takes up a bit too much space within the notification center. So let's change this by showing only 3 items by default and 6 items maximum. Toggling between the default and expanded state can be done with a button that we'll add to the footer of the table view. When the user closes and opens the notification center, we want to show it in the same state as it was before so we need to remember the expand state. We can use the NSUserDefaults for this. Using a computed property to read and write from the user defaults is a nice way to write this:

let userDefaults = NSUserDefaults.standardUserDefaults()

var expanded : Bool {
  get {
    return userDefaults.boolForKey("expanded")
  }
  set (newExpanded) {
    userDefaults.setBool(newExpanded, forKey: "expanded")
    userDefaults.synchronize()
  }
}

This allows us to use it just like any other property without noticing it gets stored in the user defaults. We'll also add variables for our button and number of default and maximum rows:

let expandButton = UIButton()

let defaultNumRows = 3
let maxNumberOfRows = 6

Based on the current value of the expanded property we'll determine the number of rows that our table view should have. Of course it should never display more than the actual items we have so we also take that into account and change our function into the following:

override func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
  if let items = items {
    return min(items.count, expanded ? maxNumberOfRows : defaultNumRows)
  }
  return 0
}

Then the code to make our button work:

override func viewDidLoad() {
  super.viewDidLoad()

  updateExpandButtonTitle()
  expandButton.addTarget(self, action: "toggleExpand", forControlEvents: .TouchUpInside)
  tableView.sectionFooterHeight = 44
}

override func tableView(tableView: UITableView, viewForFooterInSection section: Int) -> UIView? {
  return expandButton
}

Depending on the current value of our expanded property we wil show either "Show less" or "Show more" as button title.

func updateExpandButtonTitle() {
  expandButton.setTitle(expanded ? "Show less" : "Show more", forState: .Normal)
}

When we tap the button, we'll invert the expanded property, update the button title and preferred content size and reload the table view data.

func toggleExpand() {
  expanded = !expanded
  updateExpandButtonTitle()
  updatePreferredContentSize()
  tableView.reloadData()
}

And as a result we can now toggle the number of rows we want to see.

Screen Shot 2014-09-13 at 18.53.39Screen Shot 2014-09-13 at 18.53.43

Caching

At this moment, each time we open the widget, we first get an empty list and then once the feed is loaded, the items are displayed. To improve this, we can cache the retrieved items and display those once the widget is opened before we load the items from the feed. The TMCache library makes this possible with little effort. We can add it to our Pods file and bridging header the same way we did for the BlockRSSParser library.

Also here, a computed property works nice for caching the items and hide the actual implementation:

var cachedItems : [RSSItem]? {
  get {
    return TMCache.sharedCache().objectForKey("feed") as? [RSSItem]
  }
  set (newItems) {
    TMCache.sharedCache().setObject(newItems, forKey: "feed")
  }
}

Since the RSSItem class of the BlockRSSParser library conforms to the NSCoding protocol, we can use them directly with TMCache. When we retrieve the items from the cache for the first time, we'll get nil since the cache is empty. Therefore cachedItems needs to be an optional as well as the downcast and therefore we need to use the as? operator.

We can now update the cache once the items are loaded simply by assigning a value to the property. So in our success closure we add the following:

self.cachedItems = self.items

And then to load the cached items, we add two more lines to the end of viewDidLoad:

items = cachedItems
updatePreferredContentSize()

And we're done. Now each time the widget is opened it will first display the cached items.

There is one last thing we can do to improve our widget. As mentioned earlier, the completionHandler of widgetPerformUpdateWithCompletionHandler can also be called with NCUpdateResult.NoData. Now that we have the items that we loaded previously we can compare newly loaded items with the old and use NoData in case they haven't changed. Here is our final implementation of the success closure:

success: { feedItems in
  if self.items == nil || self.items! != feedItems {
    self.items = feedItems as? [RSSItem]
    self.tableView.reloadData()
    self.updatePreferredContentSize()
    self.cachedItems = self.items
    completionHandler(.NewData)
  } else {
    completionHandler(.NoData)
  }
},

And since it's Swift, we can simply use the != operator to see if the arrays have unequal content.

Source code on GitHub

As mentioned in the beginning of this post, the source code of the project is available on GitHub with some minor changes that are not essential to this blog post. Of course pull requests are always welcome. Also let me know in the comments below if you'd wish to see this widget released on the App Store.

Categories: Companies

Knowledge Sharing


SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.