Skip to content

Feed aggregator

SAFe Lean-Agile Principles Have Arrived!

Agile Product Owner - Wed, 05/20/2015 - 20:18

The impression that “our problems are different” is a common disease that afflicts management the world over. They are different, to be sure, but the principles that will help to improve the quality of product and service are universal in nature.                             —W. Edwards Deming

Why the Focus on Principles?

SAFe provides an integrated set of proven practices that enterprises rely on to improve their solution development capability. Implementation of these practices however, often requires tailoring to address the needs of a specific organization.  Should an enterprise use eight, ten or twelve week PIs? Should they have a System Team at the program or at the value stream level? Should DevOps functions be supported via a hybrid ART team or fully incorporated in each Agile team? What if you can’t integrate every day, or even every iteration? Should the trains be organized around capabilities or subsystems?

As a framework, SAFe can only take things so far, after that it’s up to the judgment of those doing the implementation. But how can SAFe provide guidance with this kind of decision-making? Answer: By clearly articulating the underlying principles that make SAFe safe.

To that end, we’ve developed nine principles that summarize the key tenets of Agile, Lean process and product development, Systems thinking and product development flow, as applied in the context of building large systems and solutions. These are the fundamental tenets, the basic truths and economic underpinnings that drive the roles and practices that make SAFe effective. Of course, you can’t possibly capture this complexity in only nine principles, but that doesn’t mean you shouldn’t try. To that end, we offer the following.

Screen Shot 2015-05-19 at 4.39.03 PM

SAFe Lean-Agile Principles

These new principles can be accessed from the new Principles tab. Each is hyperlinked to a short article that describes the principle in further detail.

The Sources

These principles incorporate lessons learned from applying Agile, Lean and SAFe practices in the field for over a decade, in a hundred different contexts. We’ve observed, recorded, drafted, revised, incorporated feedback and tried again. It’s from this field experience that we’ve observed patterns that are effective in Screen Shot 2015-05-19 at 4.46.22 PMenterprise after enterprise. Underlying these successful patterns are the principles that cause those patterns to be effective. In order to find them, you just have to dig a little further into the theory, abstract a bit, write them down, read them, and then listen to what they tell you.

Screen Shot 2015-05-19 at 4.43.42 PM

They are also derived from the Agile body of knowledge—from the Agile Manifesto to the many books and methods, Scrum, XP, Kanban—and dozens of books by the Agile thought leaders we all know so well. And in order to scale, we take our inspiration from Lean Thinking, and writings on human potential and knowledge creation from seminal and ground breaking authors Deming, Drucker, Pink, Oosterwal, Ohno, Nonaka and Takeuchi, Ries, Kim, Reinertsen, Liker, Ward, Kennedy, and many more.  Some of these books represent a lifetime of learning condensed into a few hundred pages.

We are standing on the shoulders of giants. Let’s make sure we apply all that we have learned.

Categories: Blogs

Help! My Scrum Master is Running the Sprint!

Agile Game Development - Wed, 05/20/2015 - 19:15

“Hi, I had a question.  Our Scrum Master is acting like a manager, running all the meetings and assigning work.  This is what they did before Scrum.  I thought Scrum meant the team did this stuff?” - A developer

The values of Scrum apply here.
Scrum! Scrum! Scrum! Scrum!
The sprint is the team’s commitment to a goal.  True commitment to the game and continuous improvement requires a level of ownership, otherwise it’s an environment of compliance and people don’t engage as well with that.

The barrier to allowing ownership is fear.  I often hear the micro-managing Scrum Master’s fear of what will happen if the team doesn’t follow their leadership.  "They might fail!", they cry.   There is often an underlying suspicion that others on the team are not competent because they'll make mistakes.   The news is that competence doesn't mean you don't make mistakes!

Allowing teams to make mistakes and safely fail from time-to-time requires trust and courage.  Trust requires respect.  A lack of trust and respect is a cultural root of evil.  When I see locked supply cabinets, dictated core hours or time-sheets, web filters, people referred to as “resources” etc. I know that the true adoption of Scrum will be a bit harder.

How can this be done?
Courage is requiredShifting from a mindset of individual compliance to team commitment requires courage all around.  The Scrum Master and the team must summon the courage to take chances and fail every once in awhile.  Emboldening the team to find this courage is more challenging than micromanaging via a task spreadsheet, but it’s also more fulfilling.  It doesn’t happen overnight, but trust and respect can be grown.

Scrum Masters can start with some simple things:
  1. Silence yourself! Stop doing all the talking.  Learn to allow awkward silences.  The team will fill the silence with their own ideas and solutions.
  2. Ask questions, even when you know the answer.  Teach them to catch fish rather than giving them fish to eat.
  3. Be courageous.  Demonstrate respect and protect the team.
The development team assumes a part of this challenge as well.  It’s often hard for them to shift from being assigned tasks to accepting responsibly for planning and executing their own work.  Respect and openness among each other is critical.

For example: if an artist is having problems getting code to work with a model, the entire sprint goal is threatened, but the team's focus on their shared goal should guide them to solve this problem on their own.   There is no need to blame the artist for not solving their own problem.  There is no need for someone wearing a manager’s hat to assign an engineer to fix the problem.

Does this mean managers/producers should be fired?
Don't expect leadership to
be overthrown, but leveragedAn underlying fear from managers or producers jumping into the Scrum Master role is that they should continue doing what they've been good at in the past or they'll be let go.

In the ten years that I have been training teams to use Scrum, I haven’t seen this happen.  I’m not saying it never will, but most stories I hear reflect my own as a manager in a studio that adopted Scrum.

I found that as teams became more self-organizing, there was a growing part of my time that needed to be filled with other things.  Eventually, about half my day was freed up by not micro-managing.  This wasn’t bad because the work that teams took from me was never the work I enjoyed doing.  So, I joined a team as their product owner and ended up enjoying the work far more as I was closer to the game and the people making it.

This might not be the path for every manager.  Agile should lead a studio to ask what practices and roles are benefitting their games and the people making them and what parts are not.  Again, this can threaten the status quo, which is why a lot of larger, established studios have a harder time adopting agile.

"Now I can make cool movies about
monkeys taking over the world!"The bottom line is that these values have to win out for you to have full success with agile.
Categories: Blogs

Product Owner Camp Switzerland, Sursee, Switzerland, June 11-13 2015

Scrum Expert - Wed, 05/20/2015 - 17:06
Product Owner Camp Switzerland is a three-day event for Scrum product owners and Agile product managers, coaches and ScrumMaster. The first day will be dedicated to a Product Owner Master Class. The two other days will have an open space format with discussions on how to solve problems, sharing ideas and networking with people passionately engaged in all facets of Agile product creation. Product Owner Camp Switzerland follows the open space format for conferences. Open space is a simple methodology for self-organizing conference tracks. It relies on participation by people who ...
Categories: Communities

What Happened to the Idea of Inspect and Adapt?

Scrum Expert - Wed, 05/20/2015 - 17:03
It’s all too common these days to see arguments on Twitter or mailing lists with these rules-bound zealots arguing that ”you’re not agile” because you aren’t following the rules to their satisfaction. What happened to the idea of inspect and adapt? What happened to the idea of introducing new practices, of evolving our practices to suit the challenges at hand? The canonical agile practices of popular methods have remained essentially unchanged for over a decade. We are stuck in a rut. And as I’m fond of saying, the only difference between a ...
Categories: Communities

Agile in a Bag, London, UK, June 12 2015

Scrum Expert - Wed, 05/20/2015 - 10:57
Agile in a Bag is a one-day conference that takes place in London. It proposes workshops to help you understand how Agile works and interesting presentations explaining Scrum ideas. It is also a great place to network with fellow Agile practitioners in London. In the agenda of Agile in a Bag, you can find topics like “Coaching Tools for Agile Leaders”, ” Quantifying Cost of Delay – Why is it the ‘one thing’ to quantify, How do I do it?”, “Influence techniques of Scrum Master: how to build a team without ...
Categories: Communities

Gibt es ein Leben nach dem Jobtitel?

Scrum 4 You - Wed, 05/20/2015 - 08:00

So wie bei vielen anderen Unternehmen auch gibt es auf unserem Portal mehrere Stellenanzeigen. Wir suchen wie verrückt: Senior Consultants, Senior Entwickler, ScrumMaster, Scrum Coaches etc. Vor ein paar Tagen stieß ich in diesem Zusammenhang auf einen spannenden Blogbeitrag von Johann-Peter Hartmann von Mayflower, in Deutschland bekannt für die agile Softwareentwicklung u.a. in PHP. Sein Artikel „Warum wir keine Titel und Positionen mehr haben“ hat mich sehr nachdenklich gemacht. Er schreibt: „Scrum macht jeden Sprint eine Retrospektive, um die Prozesse und Organisationsform kontinuierlich zu adaptieren. Kanban schleppt ein ganzes Sammelsurium von Messinstrumenten mit, um überhaupt feststellen zu können, wie es im Projekt aussieht und was gerade gebraucht wird. Agil fordert cross-funktionale Teams, bei DevOps wird die Brücke in den Betrieb geschlagen. Das Team ist eigenverantwortlich. Es trägt die Verantwortung selbst. Nicht der Projektleiter, nicht der Teamleiter, nicht der Senior Architect und nicht der Technical Lead. Und wenn alles angepasst werden kann, und alle Entscheidungen vom Team ausgehen, bilden Positionen und Titel da eine Ausnahme? Alles darf angepasst werden, nur die Titel und Positionen nicht? Das Team darf entscheiden und ist verantwortlich, ausser da ist ein Technical Lead, ein Architect oder ein Team Lead?”

Johann-Peter hat damit natürlich vollkommen recht und diese Frage ist genial. Sie zeigt, dass man am Ende auch die eigene Organisation hinterfragen muss. Doch wie wirkt das nach außen? Findet man Entwickler oder Consultants, wenn man nicht explizit nach z.B. „Senior Consultants“ sucht? Ich denke, das ist schwer und das schreibt er auch: „Und dann kommt die Irritation. Denn sie (die Bewerber) wollen Teamleiter, C*O, irgendwas mit Personalverantwortung, Head of *, * Lead oder Senior Architect werden. Auf gar keinen Fall einfach nur Developer. Nein, ein Titel muss her, man will ja die eigene Leistungsfähigkeit in der Karriere abgebildet sehen. Tja, und damit können wir – und viel wichtiger wollen wir – gar nicht dienen. Weder die HR-Abteilung noch die Geschäftsführung kann Leute auf Positionen einstellen oder einen Titel vergeben. Denn die existieren bei uns nicht mehr.”

Diese Idee, dass es keinerlei Positionen mehr gibt und dass es sich natürlich auch auf die Stellenanzeigen auswirkt, ergibt Sinn. Aber Moment … jemand vergibt die Jobs und wählt aus. Der Gesetzgeber verlangt zum Beispiel bei einer GmbH einen Geschäftsführer, der im Interesse der Gesellschaft handelt und möglicherweise sogar die Interessen der Gesellschaft gegen die Interessen der Gesellschafter abwiegt. Er ist also mit Leib und Seele gesetzlich in der Position der Gesamtverantwortung gebunden, ob er das nun persönlich will oder nicht.

Real existieren mehrere Konflikte, die diesem Gedanken auf den ersten Blick widersprechen:

  1. Die Bilder im Kopf der Mitarbeiter
  2. Die gesetzlichen Rahmenbedingungen
  3. Die gelernten Reflexe von Mitarbeitern und Management
  4. Das Umfeld, in dem diese Firmen arbeiten – denn die Kunden wollen oftmals mit dem Senior XY arbeiten.
  5. Die Gesellschafter/das Board – wollen die auch agil?

Nun kann man solche Überlegungen natürlich als Fatamorgana abtun und entgegenhalten: “Das ist altes Denken, traditioneller Quatsch!“ Doch Phänomene weisen uns immer auf etwas hin: Dass da etwas ist – ein zugrunde liegendes Bedürfnis, ein tief sitzender Faktor, der immer mitschwingt und vielleicht erst überwunden werden muss.

Ich kann nur von meinem eigenen kleinen Unternehmen erzählen, denn auch bei uns sind Aufstieg und Verantwortung, Gehaltserhöhungen, Selbst- und Fremdwahrnehmung immer wieder ein Thema. Warum eigentlich? Wir sind “leading edge“ im agilen Umfeld. Wir wissen, was agile Führung bedeutet und wohin der Zug fahren sollte. Wieso straucheln auch wir immer wieder? Ist es, wie ich dem Gespräch mit einem Professor der Psychologie entnommen habe, die Sozialisation? Haben uns die Gesellschaft, Schule, Familie (soziologisch gesprochen: die Institutionen) so geprägt?

Wenn die Graugans in uns schnattert

Ich vermute, die tieferliegende Ursache hinter alledem ist das Thema Rang = Status. Soziale Wesen wollen wissen, in welchem Verhältnis sie zu den anderen stehen – also auf welcher Rangstufe. Das mag jetzt zu simpel sein: Konrad Lorenz war der erste, der das am Verhalten von Graugänsen gezeigt hat. Sofern mich die Erinnerung an meine Biologie-Schulstunden nicht täuscht, arbeitete er heraus, wie wichtig die Hackordnung in sozialen Verbänden ist. Schaut man sich die neueren Erkenntnisse der Neurologie an, so ist genau der Status für uns alle immer ein Thema. Status ist wichtig, weil wir uns in sozialen Verbänden nur dann sicher fühlen, wenn wir wissen, wo wir stehen. Die bereits von Lorenz beschriebenen Phänomene sind u.a. Ausdruck dessen, dass etwas in uns nach Status (Rang, Titel usw.) strebt. Wir alle wollen Auszeichnungen, wir wollen Preise gewinnen und uns von der Masse abheben, Rangkämpfe sind „normal“ und gehören dazu. Sie sind nicht etwa Ausdruck von Machtgier, sondern entstehen aus dem Bedürfnis nach Sicherheit in der Gruppe. Alle, nicht nur „agile“ Teams, erleben diese Suche nach dem Platz in der Gruppe als Verunsicherung in der Storming Phase. Als Wissenschaft ist die Soziologie entstanden, um den Menschen aus der Unmündigkeit der nicht verstandenen Herrschaftsbeziehungen zu befreien. Soziobiologisch sind wir aber in diese Statuskämpfe hineingezwungen und vieles in unserem menschlichen Verhalten lässt sich tatsächlich auf diese Instinkte zurückführen. Aber sind wir ihnen ausgeliefert? Nur dann, wenn wir sie nicht erkennen und uns nicht von ihnen befreien.

domestic-goose-402228_1280

Pixabay

Agilität ist eine bewusste Entscheidung

Agiles Arbeiten ist u.a. der Versuch, sich dieser Instinkte bewusst zu werden und immer und immer wieder dagegen anzugehen, um die menschliche Natur zu kultivieren.
Die Beispiele, die in „Reinventing Organizations“, in meinem Buch „Selbstorganisation braucht Führung“ und auch im Blogbeitrag von Johann-Peter Hartmann zu lesen sind, schüren die Hoffnung, dass Menschen in Teams und Organisationen beginnen, diese Zusammenhänge zu verstehen und sich immer wieder bewusst gegen das Eingefahrene entscheiden. Das ist extrem anstrengend für alle Beteiligte. Aber Verhalten lässt sich ändern, auf unterschiedliche Weise. Es beginnt mit dem Glauben daran, dass dieses andere Verhalten für alle befreiender ist und uns glücklicher, gesünder und erfolgreicher macht. Diese bewusste Entscheidung ist es, die uns in die Richtung des agilen Managements führen wird.

Ich finde es toll, dass es Mayflower gelungen ist, die Titel intern abzuschaffen. Ich würde mich sehr freuen, wenn wir in den kommenden Jahren noch öfter solche Artikel von verschiedenen Unternehmen lesen könnten. Ein Beispiel habe ich noch: Seht euch mal die Firma liip.ch an. Gerhard Andrey hat bei der BWI Fachtagung in Zürich wunderbar erklärt, wie sie es in ihrem Unternehmen umgesetzt haben. Er erzählte über Open Source, über Teams und die Guilds (für die man sich u.a. bewerben muss). Toller Vortrag.

Übrigens: Beim nächsten Treffen des Software Forums Leipzig im November werden wir das Thema Führung und Selbstorganisation beleuchten und miteinander diskutieren. Vielleicht macht ihr mit?

Categories: Blogs

Neo4j: Finding all shortest paths

Mark Needham - Wed, 05/20/2015 - 00:45

One of the Cypher language features we show in Neo4j training courses is the shortest path function which allows you to find the shortest path in terms of number of relationships between two nodes.

Using the movie graph, which you can import via the ‘:play movies’ command in the browser, we’ll first create a ‘KNOWS’ relationship between any people that have appeared in the same movie:

MATCH (p1:Person)-[:ACTED_IN]->()<-[:ACTED_IN]-(p2:Person)
MERGE (p1)-[:KNOWS]-(p2)

Now that we’ve got that relationship we can easily find the shortest path between two people, say Tom Cruise and Tom Hanks:

MATCH (p1:Person {name: "Tom Hanks"}), (p2:Person {name: "Tom Cruise"}),
      path = shortestpath((p1)-[:KNOWS*]-(p2))
RETURN path
Graph  18

That works pretty well but what if we want to find the longest shortest path between any two people in the graph? We can calculate it like this:

MATCH (p1:Person), (p2:Person),
      path = shortestpath((p1)-[:KNOWS*]-(p2))
RETURN path
ORDER BY LENGTH(path) DESC
LIMIT 1
Graph  19

So that’s 6 hops which is actually the Bacon number – I expect we’d probably see a smaller maximum value if we imported all the movies.

And to round off the post what if we want to find the longest shortest path between the 10 people who acted in the most movies? We might start out with the following query which seems like it should do the job:

MATCH (p1:Person)-[:ACTED_IN]->()
 
WITH p1, COUNT(*) AS appearances
ORDER BY appearances DESC
LIMIT 10
 
WITH p1 AS p1, p1 AS p2
MATCH path = shortestpath((p1)-[:KNOWS*]-(p2))
RETURN path
ORDER BY LENGTH(path) DESC
LIMIT 1

Unfortunately if we run that query we get no rows returned because ‘p1′ and ‘p2′ always refer to the same node.

Instead we can calculate the shortest path between our hardest working people by creating a cross product using COLLECT and UNWIND:

MATCH (p1:Person)-[:ACTED_IN]->()
 
WITH p1, COUNT(*) AS appearances
ORDER BY appearances DESC
LIMIT 10
 
WITH COLLECT(p1) AS ps
UNWIND ps AS p1 UNWIND ps AS p2
MATCH path = shortestpath((p1)-[:KNOWS*]-(p2))
RETURN path
ORDER BY LENGTH(path) DESC
LIMIT 1

Graph  20

That’s all for now!

Categories: Blogs

Agile Is Supposed To Be Simple…

Leading Agile - Mike Cottmeyer - Tue, 05/19/2015 - 20:37

I was reading about the new iteration of SAFe that came out a few days ago. I appreciate what Dean is doing with SAFe and totally get the problem he is trying to solve. That said, it makes me wonder how folks receive the ever growing complexity of the model.

Fundamentally, we have two choices as leaders of companies.

We can model and manage the complexity inherent in the system, or we can reduce that complexity. What we can’t do is pretend the complexity doesn’t exist and fail to do something about it. So often I see agile implementations that want to ignore what’s really going on.

This is too complex, agile is supposed to be simple.

True, but agile is also supposed to be 6-8 people sitting in a room with an onsite customer. Teams are supposed to have autonomy. Teams are supposed to have the power to decide. Teams are supposed to have the ability to change direction when they learn new stuff.

You can’t have your cake and eat it too.

It’s naive to think that three roles, three ceremonies, three artifacts are going to fix everything in your organization. It’s naive to think that you can self-organize the complexity away. It’s naive to think that companies are going to stop caring about when and how stuff is going to get done.

So again, we come back to two fundamental choices for making all this work. Model and manage the complexity in the system, or make the system less complex. It’s your call.

The post Agile Is Supposed To Be Simple… appeared first on LeadingAgile.

Categories: Blogs

The Scrum Values

Agile Game Development - Tue, 05/19/2015 - 19:28
The Scrum Values
  • Focus. Because we focus on only a few things at a time, we work well together and produce excellent work. We deliver valuable items sooner.
  • Courage. Because we are not alone, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges.
  • Openness. As we work together, we practice expressing how we're doing, and what's in our way. We learn that it is good to express concerns, so that they can be addressed.
  • Commitment. Because we have great control over our own destiny, we become more committed to success.
  • Respect. As we work together, sharing successes and failures, we come to respect each other, and to help each other become worthy of respect.


Categories: Blogs

NeuroAgile Quick Links #12

Notes from a Tool User - Mark Levison - Tue, 05/19/2015 - 17:32
A collection of links to interesting research from the world of neuroscience and behavioural psychology that can be applied (or not) to Agile/Scrum Teams. original graphic design by Freepik
Categories: Blogs

End-to-End Hypermedia: Making the Leap

Jimmy Bogard - Tue, 05/19/2015 - 17:26

REST, a term that few people understand and fewer know how to implement, has become a blanket term for any sort of Web API. That’s unfortunate, because the underlying foundation of REST has a lot of benefits. So much so that I’ve started talking about regular Web APIs not as “RESTful” but just as a “Web API”. The value of REST for me has come from the hypermedia aspect of REST.

REST and hypermedia aren’t free – they significantly complicate both the building of the server API and the clients. But they are useful in certain scenarios, as I laid out in talking about the value proposition of hypermedia:

  • Native mobile apps
  • Disparate client deployments talking to a single server
  • Clients talking to disparate server deployments

I’ve only put one hypermedia-driven API into production (which, to be frank, is one more than most folks who talk about REST). I’ve attempted to build many other hypermedia APIs, only to find hypermedia was complete overkill.

If your client is deployed at the same time as your server, lives in the same source control repository, hypermedia doesn’t provide much value at all.

Hypermedia is great at decoupling client from server, allowing the client to adjust according to the server. In most apps I build, I happily couple client to server, taking advantage of the metadata I find on the server to build highly intelligent clients:

@using (Html.BeginForm()) 
{
    @Html.AntiForgeryToken()
    
    <div class="form-horizontal">
        <h4>Instructor</h4>
        <hr />
        @Html.ValidationDiv()
        @Html.FormBlock(m => m.LastName)
        @Html.FormBlock(m => m.FirstMidName)
        @Html.FormBlock(m => m.HireDate)
        @Html.FormBlock(m => m.OfficeAssignmentLocation)

In this case, my client is the browser, but my view is intelligently built up so that labels, text inputs, drop downs, checkboxes, date pickers and so on are created using metadata from a variety of sources. I can even employ this mechanism in SPAs, where my templates are pre-rendered using server metadata.

I don’t really build APIs for clients I can’t completely control, so those have completely different considerations. Building an API for public consumption means you want to enable as many clients as possible, balancing coupling with flexibility. The APIs I’ve built for clients I don’t own, I’ve never used hypermedia. It just put too much burden on my clients, so I just left it as plain old JSON objects (POJSONOs).

So if you’ve found yourself in a situation where you’ve convinced yourself you do need hypermedia, primarily based on coupling decisions, you’ll need to do a few things to get a full hypermedia solution end-to-end:

  • Choose a hypermedia-rich media type
  • Build the server API
  • Build the client consumer

In the next few posts, I’ll walk through end-to-end hypermedia from my experiences of shipping a hypermedia API server and a client consumer.

 

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Categories: Blogs

Is Your Program Team Just a Messin’ an a Gommin’?

Leading Agile - Mike Cottmeyer - Tue, 05/19/2015 - 15:09

A long, long, well… long time ago when I was a young man, my Grandma Lossie would get all dressed up and her best friend Gladys would come pick her up for a night out. When I asked those two what they were up to, one of these two south Georgia ladies would always say, “We are just a messin’ an a gommin’!”  It was at this point that I always insinuated they were going out to pick up younger men.  They would cackle, but they really meant that they were messing around doing nothing and having a bit of fun.

Outside looking in, it can often seem like agile teams are “messin’ and a gommin”.  Especially if you aren’t in the value stream yourself.  So make sure you pay close attention, go to demos, etc. before passing judgement.   Here is a partial list of things that I expect a Program Team to do in a larger agile system.

A Program Team (or product owner team) is the second tier in larger agile systems. The following are a set of thoughts for new agile Program Teams that I stand up. I’ll start with a restating of why they exist and move into what these teams do day-to-day.

Making Agile work… a refresher

To make agile work you need:

  • Clarity in your backlog
  • A team that stays together
  • A cross-functional team that can produce working tested software
Two Key Areas

During the day-to-day work, a Program Team has two areas of focus. They create a clear backlog that teams can consume by creating an actionable release plan. They deliver on a release plan commitment.

Delivery

During Delivery a Program Team collectively fills the traditional product owner role by:

  • Prioritizing work, making tradeoffs, and reducing risk early
  • Providing architectural guidance to ensure longer roadmap views are considered and to guard against overbuilding by building the simplest possible thing
  • Giving clear test guidance to simplify automation strategies and balance manual and automation testing
  • Providing visual guidance when, and only if, needed for clarity to delivery teams
  • Breaking down larger stories to reduce risk early in the release

The Program Team does this in order to hold themselves accountable for the quality of the product, the rate of delivery, and the long-term survivability of the product.

Release Planning

During planning a Program Team provides clarity by:

  • Making an actionable backlog that can be completed by the agile teams
  • Performing Rapid Feature identification and story mapping
  • Defining features and stories “clear enough” as the way to maximize throughput of the Program while maintaining predictability

During Planning a Program Team provides a credible plan by:

  • Performing breakdown not to the scenario level, but rather to a level that can fit into a sprint. Remember that during Delivery program team will elaborate on big stories to reduce risk
  • Not planning on dependent story points. The only dependencies accepted should be those where the dependency has a track record of consistently delivering on commitments. Any other acceptance really isn’t credible
  • Providing architectural guidance to ensure longer roadmap views are considered

Planning and Delivery, that’s what Program Teams focus on every day. Their retrospectives should focus on these areas. Keep in mind that this is a beginning and not an end goal. While this is a rational place to start, most will have problems getting here because they can’t form teams, can’t define an actionable, clear release plan, or they don’t have the ability to produce product with a cross-functional team.  If you are ready to do those things great, if not you just might be “Messin’ an a Gommin” so get help.

The post Is Your Program Team Just a Messin’ an a Gommin’? appeared first on LeadingAgile.

Categories: Blogs

Agile Coach Camp Italy, Cavalese, Italy, June 4-6 2015

Scrum Expert - Tue, 05/19/2015 - 15:02
Agile Coach Camp Italy is a two-days of highly collaborative, self-organized open space conference. It’s for everyone involved in coaching, training, mentoring and helping Agile organizations. Agile Coach Camp Italy follows the open space format for conferences. Open space is a simple methodology for self-organizing conference tracks. It relies on participation by people who have a passion for the topics to be discussed. There is no preplanned list of topics, only time slots and a space in the main meeting room where interested participants propose topics and pick time slots. Web site: ...
Categories: Communities

Failing to Plan is Planning to Fail: Succeed with Agile Planning Framework and its Four Planning Levels

Agile Management Blog - VersionOne - Tue, 05/19/2015 - 14:29

Many people know that agile planning is different from big up-front detailed planning done in traditional or waterfall projects.  However, there are many misconceptions or only partial understandings of agile planning.

In this first blog post in a series of six, I will begin to explain the details of agile planning: what and why, and multi-level planning and its benefits.

What is Agile Planning?

Some people equate agile planning with minimal planning or just-in-time planning or “fluid” or “adaptive” planning or planning to be done by the whole team not managers – all these characterizations cover only some aspects of agile planning.  Agile planning is more involved, more disciplined, and rigorous than what some people think.

If done right, agile planning requires modest time and effort. This planning effort should not be viewed as an overhead, or a chore to be done by “agile project managers”. Planning is part of the overall work. If you don’t plan or plan poorly, no amount of execution effort would adequately compensate for poor agile planning. “Winging” an agile plan is expensive and doesn’t work well. As Benjamin Franklin said, “If you fail to plan, you are planning to fail!

The Agile Planning Framework is based on multiple levels of planning – typically four levels – as illustrated in Figure 1.

  • Level 1: Product vision and strategy planning – this is the top level of planning
  • Level 2: Release planning
  • Level 3: Sprint planning
  • Level 4: Daily planning and daily Scrums – this is the bottom level of planning

Figure 1 also illustrates the key goals at each of four planning levels.  Each level of planning is elaborated and supported by the next lower level of planning at smaller planning units, but with greater details (elaboration) and on a shorter planning time horizon, as will be explained soon.  Figure 1 is based on a popular poster from VersionOne that you may download for your use.

Fig1_Planning_Levels

Figure 1: Four Levels of Agile Planning

The Three Agile Planning Roles

Note that these are roles, and not necessarily three distinct sets of people.  Many planners also implement the plan, and many implementers are involved in planning.  In many organizations, the same person may play one or more of these roles. A sprint planner could be a team member doing his/her Daily planning and may also be a release planner. A release planner could also play the role of an agile champion. A software architect could be a team member, sprint planner, release planner, product vision and strategy planner, and agile champion. Each team member is a daily planner and is expected to work and deliver on that daily plan.

1. Agile champions: Agile champions are responsible for implementing, maintaining and improving an organization’s customized agile planning playbook by briefly and effectively documenting the agile planning process at each level as well as evangelizing and teaching the planning process to agile planners. The champions also revise and improve the agile planning playbook based on the feedback from agile planners, agile team members, as well as changing market conditions, competitive response, business conditions, technology changes, etc.

These agile champions are the owners of your agile planning playbook. They may be senior executives or senior managers responsible for your organization’s agile transformation. They could also come from your enterprise’s agile Project Management Office (PMO) or they may be a group of enthusiastic and committed ScrumMasters if the agile initiative is started at the team level.

2. Agile planners: Agile planners are responsible for following the agile planning playbook to conduct planning and do re-planning as is necessary. An agile plan needs to be revised and adjusted at an appropriate frequency (based on the agile planning level) based on the feedback from agile team members, stakeholders, and also from the environment, as explained below. Agile planners work with the appropriate stakeholders to seek their input, guidance and expertise in the planning process.

3. Agile team members: Agile team members are responsible for day-to-day work of developing, delivering, deploying, operationalizing and supporting agile project deliverables after each sprint and release cycle. This day-to-day work is driven by agile plans developed by the planners at each level. These self-organized team members should have cross-functional expertise in areas of analysis, software design, user experience design, code development, testing, technical writing, data center deployment and operations, etc. Note that agile team members are not only daily planners, but also sprint planners; some of them may participate in release planning, and some may be called upon to help in product vision and strategy planning.

The Four Guidelines for Agile Planning

1. Plan and elaborate progressively at each planning level: Planning done at each level is a pre-requisite for the next lower level of planning. It serves as the context and guides planning at the next lower level.  Product vision and strategy planning (Level 1) should proceed in the context of completed planning at the business vision and strategy done by senior C-level executives responsible for overall business; as this planning is related to the overall enterprise business, it is outside in the scope of this blog series.   Without a reasonable business vision and strategy in place, planning product vision and strategy is difficult and ineffective.  Release planning (Level 2) should proceed in the context of completed planning at the Product vision and strategy (Level 1).   Without a reasonable product vision and strategy in place, Release planning is very difficult.   Sprint planning (Level 3) should proceed in the context of completed release planning (Level 2).  Without a reasonable Release plan in place, Sprint planning could be difficult or at best tactical.  Daily planning and daily Scrums (Level 4) should proceed in the context of completed sprint planning (Level 3).  Without a reasonable sprint plan in place, daily planning is not very effective.  It is not advisable to plan at a level and then skip one or two levels to jump to a lower level; for example, starting at planning level 1, skipping Level 2, and jumping to Level 3 should be avoided.

2. Choose proper planning horizon, and granularity of planning and workflow monitoring at each level of planning: Planning time horizon should start with a typical 1 to 3 year range at Level 1 (product vision and strategy) and should shrink to a single workday at Level 4 (daily planning and daily Scrum). As planning time horizon shrinks, the granularity for planning and workflow monitoring should also shrink from “very large” (at Level 1) to “very small” (at Level 4).

Level 1 – Product vision and strategy planning: Large to very large planning and workflow monitoring units, such as product goals and initiatives, strategic themes. These units are typically modeled as initiative epics and may take several months or release cycles to complete.

Level 2 – Release planning: Moderate planning and workflow monitoring units, typically modelled as feature epics that can be completed in a single release cycle consisting of multiple sprints.

Level 3 – Sprint planning: Small planning and workflow monitoring units, such as user stories and other work items (defects, spikes, regression test cases, etc.) that can be completed in a single sprint.

Level 4: Daily planning and daily Scrum: Very small planning and workflow monitoring units which are SMART tasks that implement a story or a work item. A SMART task is completed typically in four hours or less in a single workday.  Acronym SMART stands for: S: Small, M: Measurable, A: Achievable, R: Realistic and T: Time-bound

With longer time horizon, it makes sense to plan and monitor workflow at larger granularity of work. When planning horizon is long-term (Level 1 planning), working on small or medium-grain planning units (stories and epics) makes little sense as those small work items usually are not even known during Level 1 planning, and it would be a wasteful practice as many small work items will almost certainly change over time even if we spend effort to identify and model them during Level 1 planning.

3. Identify proper agile planners and stakeholders that must work together with commitment to required planning preparation and allocation of required planning time: Agile champions in your organization should identify the right planners and appropriate stakeholders at each level of planning, and those agile planners must work with the right stakeholders effectively. Agile planners must be well prepared and committed to attend all planning meetings and workshops with their quality time and focus without interruptions.  This often requires a cultural change in many organizations, and may need executive support and sustenance.  This also requires training of agile planners and stakeholders, and guidance by qualified coaches to conduct agile planning workshops at each level of planning.

Product vision and strategy planners and their planning time: Executives work with Product manager and other appropriate stakeholders. Three to nine days of planning effort is typically required depending on the product size, duration and complexity for a one to three year product horizon (240 workdays per year). A product vision and strategy plan should be revised or fine-tuned at the end of each release cycle.  If you consider additional one to three days of effort to maintain and revise the Product Vision and Strategy Plan, it still amounts to only 2% of total time for planners at this planning level.

Release planners and their planning time: Release manager, product owner, ScrumMaster and team leads work with managers and representatives of other related release teams (for large projects). Two to four days of planning effort is typically required for a three to six months release cycle (22 workdays per month).  A release plan should be revised at the end of each sprint cycle.   If you consider additional 0.5 to 1 day of effort to maintain and revise the release plan, it still amounts to a very modest 4% of total time for planners at this level of planning.

Sprint planners and their planning time: The whole team (all its members) does planning and works with managers and representatives of other related teams (for large project). Four to eight hours of planning effort is typically required for a two- to four-week sprint (five workdays per week). This amounts to a modest 5% of total time for planners at this level of planning.

Daily planners and time for planning and attending Daily Scrums: Each team member plans his/her individual daily work, typically requiring 10 minutes of daily personal work planning effort.  This planning must be completed prior to each daily Scrum meeting which takes another “2n+5” minutes, where “n” is the number of team members in a team (see my blog series on how to make Daily Scrums Effective and Efficient); it takes two minutes for each team member to present his/her daily work plan and to report against the plan of the previous workday (tasks done or not done), and another five minutes for the team to review key metric such as the burn-down and burn-up reports.  Thus it takes 15 to 23 minutes per day (depending on the size of the team ranging from 5 to 9 cross-functional, self-organized team members) to conduct the daily Scrum meetings.  The total time to prepare the daily plan and attend the daily Scrum is 25 to 33 minutes.  This amounts to a modest 5% to 7% of total time for each team member.

In future blogs of this blog series, I will present the details of the recommended schedule and cadence for the planning sessions at all four planning levels.

4. Define workflows at each level of planning and execution:

Each higher level of planning sets the context and drives the work at lower levels of planning as illustrated in Figure 2.  Agile planners must define the workflow at each level of planning.  As shown in Figure 2, at Product Vision and Strategy planning level, work items are modeled as Initiative epics and they flow in sequential stages: Approve and Fund, Implement, Deployed, and Measure Return on Investment (ROI).   As an Initiative epic reaches Implement status, it signals that work can be initiated at the next lower level, i.e., Release planning level.  An Initiative epic gives rise to many Feature epics at the Release planning level; when a feature epic is broken down into stories and reaches the Build status, it signals that work can be initiated at the Sprint planning level.  When a user story reaches Development status in a sprint, its SMART tasks are pulled by individual team members to work on and their workflow is monitored on the Taskboard as part of Daily workflow.  When all tasks for a story are completed, the story is Accepted by Product Owner (assuming it passes all its acceptances tests), and gets Deployed.  When all stories for a Feature epic are Deployed, that Feature epic moves to Deployed status on Feature Epicboard.  When all Feature epics of an Initiative epic are Deployed, the Initiative epic moves to Deployed status on the Initiative Epicboard.

Agile planners need to define policies for managing workflows at each level (rules for status transitions); and board-level policies, such as Work-in-Process (WIP) limits, cycle time thresholds, etc.   There is plenty of opportunities to customize the workflows, status columns, and policies at each level of planning.   I will explain the workflow at all four planning level in four future blogs of this blog series.Fig2V4_Workflows

Figure 2: Customizable Workflows at Each Agile Planning Level

Agile Planning Playbook

As my colleague Mike McLaughlin explained in his agile playbook blog, an agile playbook is a helpful guide that briefly documents your agile process. I believe an agile lifecycle playbook should cover the entire value stream from product vision, strategy, analysis, design, development, testing, delivery, deployment, operations, support, and customer value realization. These are not sequential phases of work; often agile team members “swarm” to do many tasks concurrently and in close harmony, such as analysis, design, development, testing; and even deployment and operations as the DevOps movement proposes.

An agile lifecycle playbook helps ensure consistency among projects and teams, improves their productivity and quality of work and reduces mistakes and errors. VersionOne’s 9th Annual State of Agile™ survey has indicated that the consistent process and practices is the top tip for success in scaling agile.    You can and should start using your agile lifecycle playbook even with single teams and smaller projects to ensure consistency across successive sprints, and improve your playbook with on-going experience.

An agile planning playbook focuses on agile planning aspects of the agile lifecycle, and is a part of the overall agile lifecycle playbook for your organization. Your agile planning playbook facilitates agile planning in a standard and consistent way across the whole enterprise or at least across a set of common projects or teams. There is no “one size fits all” agile planning playbook that suits all organizations.

Consider these very different types of organizations.

  • A relatively small company working on its next product over multiple release cycles with four agile teams consisting of a total of 35 members
  • A large bank with portfolios of many projects consisting of 1,200 project members and developing software for in-house use
  • An organization developing and operating a large e-Commerce service through Internet cloud
  • A Department of Defense contractor developing a mission-critical system (hardware and embedded software) spanning five years of development cycle

Each organization, product, program or project, as well as teams and people and their practices, history and cultures are unique.  Therefore each organization or a division or a line of business will need a customized agile lifecycle playbook and agile planning playbook to serve its unique needs and business goals. However, agile planning needs of diverse organizations share a common core based on agile principles, values, and agile framework.

The Agile Planning Framework is based on a common core of agile planning principles and practices.  The framework is common for all organizations interested in agile development. Your organization can develop one or more agile planning playbooks from the common framework by customizing and implementing it in ways that best serves your needs.

Most of the material in this blog series is written with a focus on the lifecycle of software products or services or embedded software products that are intended for multiple customers in their chosen market segment.  With appropriate modifications, you can use this framework for a number of different situations, such as:

  • Single client-specific custom software project
  • An entrepreneurial start-up company with a lot of uncertainty
  • Scaled agile environments where there may be many portfolios of programs and projects

I will explain how you can modify the Agile Planning Framework to suit these different situations throughout this blog series.

The next five blogs of this blog series: In the next blog (Blog 2 of this series), I will explain four objectives at each planning level of the Agile Planning Framework.   In the following four blogs (Blog 3 to 6), I will explain the implementation and customization details for four practices needed to realize the four objectives at each planning level.

  • Blog 3: Plan and Succeed Strategically using Your Agile Product Vision and Strategy Planning Playbook
  • Blog 4: Plan and Succeed in each Release using Your Agile Release Planning Playbook
  • Blog 5: Plan and Succeed in each Sprint using Your Agile Sprint Planning Playbook
  • Blog 6: Plan and Succeed every Day using Your Agile Daily Planning and Daily Scrum Playbook

In Blog 6, I will also present a complete example of an Agile Planning Playbook based on the Agile Planning Framework.

Your feedback: I would love to hear from the readers of this blog either here or by e-mail (Satish.Thatte@VersionOne.com) or on Twitter (@smthatte).


versionone-coaches-satish-thatteAbout the Author

Dr. Satish Thatte
SPC, CSM, CSPO, CSP

Dr. Satish Thatte is Agile/Lean Coach & Product Consultant at VersionOne. He has over 30 years of industry experience, covering 15 years of software development and management at Texas Instruments, Bellcore and LG Electronics, 7 years as VP of Engineering at several companies practicing agile methods, and 6 years of agile coaching and consulting engagements for over 50 clients with impact at the executive level. He obtained his MS and PhD degrees in Electrical and Computer Engineering from the University of Illinois at Urbana-Champaign.

His expertise is in application of agile-lean methods and getting business results, agile transformation, and scaling up agile methods. He has been a speaker at a number of organizations and events: NYC Scrum, NY SPIN, NJ SPIN, Philly SPIN and AgilePalooza. He is a member of the Scrum Alliance, Agile Alliance, and a Senior member of the IEEE, and has served as Director of Modeling and Simulation at the Conscious Capitalism Institute. Learn more about Satish and his blogs at LinkedIn and blogs.

Categories: Companies

Scrum Alliance Partners With Front Row Agile

Scrum Expert - Tue, 05/19/2015 - 14:00
Scrum Alliance has announced a partnership with Front Row Agile to provide valuable online training to its more than 400,000 members worldwide. The online courses will be available to members at a 50 percent discount and will count toward members earning Scrum Education Units (SEUs). Members need SEUs to grow in the practice of Scrum and get to the next levels of certifications with Scrum Alliance. “We have no doubt there is a strong and growing interest in Scrum throughout the world, and we believe offering our members online courses will ...
Categories: Communities

News update 2015/05 – 25% discount off Leading Self-Organising Teams course

ScrumSense.com - Peter Hundermark - Tue, 05/19/2015 - 13:37

Joanne Perold has written a very interesting piece on why she feels dysfunction in an organisation is often attributed to competing KPIs. The current incarnation of KPIs in most organisations is reinforcing the dysfunction and not solving the right problems. Instead we need to ask ourselves, “What is the problem we are trying to solve?”

This month’s blog post, ‘Are incorrectly applied KPIs the root of all evil‘  is well worth the read!

Simple Agile Leadership ModelLeading Self-Organising Teams course

We are offering an early-bird special on our upcoming Leading Self-Organising Teams course. Book before the 31st May 2015 and receive a 25% discount!

Learn and practice leadership skills based on a state-of-the-art model for Lean/Agile leadership. Develop mastery in an essential set of people-related skills that complement the technical skills you already possess. Take charge of your own leadership development!

Join us on the 07-08 July 2015 in Sandton to broaden your leadership knowledge. Click HERE for more info.

Upcoming Courses

Certified Scrum Product Owner (JHB)
02-03 June 2015
FNB Conference & Learning Centre, Sandton

Certified Scrum Master (JHB)
23-24 June 2015
FNB Conference & Learning Centre, Sandton

Certified Scrum Product Owner (CPT)
29-30 June 2015
Steenberg Hotel, Cape Town

Leading Self-Organising Teams (JHB)
07-08 July 2015
FNB Conference & Learning Centre, Sandton

Course Schedule and Book Online

The post News update 2015/05 – 25% discount off Leading Self-Organising Teams course appeared first on ScrumSense.

Categories: Blogs

Addendum to How to Abandon Practices

NetObjectives - Tue, 05/19/2015 - 13:02
In our Day 3 of SAFe: Elaborating SAFe, the fourth webinar on Leanban, I discussed how to abandon practices.  Here were a couple of other tables of interest.  This relates to my earlier blog How to Abandon Practices. Focus on Outcomes, Not Practices Outcome to Achieve Scrum Kanban What to Do Coordination with other teams Time-boxes all in synch Use cadence all in synch Use...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

RSpec and the Death of Should

I love writing expectations like the following:

1
account.balance.should be_zero

It was one of the reasons I first fell in love with RSpec and had a reason to move from dabbling in Ruby to diving in. This was hard and clear evidence that Ruby crushed testing syntax of Java in a way it could never compete with. Just a beautiful DSL with a single little word ‘should’.

Expect has come along to replace and it accomplishes the same thing with a bit more syntax and parens:

1
expect(account.balance).to be_zero

It reads well, but I still like ‘should’ better and I’m not as upset as some about object purity and polluting objects with an extra method. Our development team concluded as much for the last few years. We’d put a quick vote up every 6 months or so to keep should() or bite the bullet and move onto expect. Should always won, but over time the objections became more mild and newer team members had gotten adjusted to expect elsewhere. When the vote came up again a few weeks back, we finally voted to default to the new expect syntax.

My vote had changed from preferring should to being neutral on it. Over time most of that came from working on newer Ruby open source projects and following the new expect syntax when adding tests in a pull request. Idioms and styles evolve and I’d seen enough adoption to justify retiring my old friend should(). The small benefit has been with Jasmine with its very similar expects now doesn’t lead to accidentally writing a should() in a Jasmine spec. I still miss should(), but having everyone use the same assertion approach is better for the group.

Categories: Blogs

Major SAFe LSE Update with Big Implications

Hello Folks,

As you probably know, I’ve moved most of my blogging activity to the Scaled Agile Framework Blog. For a major update on SAFe LSE and the future of SAFe, check out this post.

I’ll be maintaining this blog for just a while longer. As the SAFe blog is dedicated to SAFe content, I plan to start my personal blogging again on my website at deanleffingwell.com. I’ll be describing a few other topics I’ve been researching lately, and some great books and background reading, all of which is too early for SAFe.

–Dean

Categories: Blogs

Knowledge Sharing


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