Skip to content

Blogs

Managing Manager-less Processes

TV Agile - Wed, 06/21/2017 - 18:25
A new generation of Agile processes are emerging, frequently omitting the role of a dedicated manager. Erik Meijer has termed his flavor as One Hacker Way; my version was originally titled Programmer Anarchy. We explore the reasons for the emergence of these managerless processes, suggesting they are particularly appropriate for solving “fuzzy problems” (Complex problems […]
Categories: Blogs

Sprints or a Kanban?

Agile Game Development - Wed, 06/21/2017 - 15:45
There seems to be some confusion that using Sprints or a Kanban is a competition of sorts with "one being better than the other".  Might as well argue whether a hammer is better than a saw.

Sprints are more suitable to complex problems that a cross-discipline team will swarm on to solve.  Complex work has "unknown unknowns" that require experimentation and defy planning and estimation.  The time-box is a limit of time that is established to touch base with the business side and to replan our next move on a complex mechanic.

A Kanban, a way to visualize a lean flow, is used for complicated work.  Complicated work has "known unknowns", like creating levels and characters for a game with established mechanics.  The variations are manageable. It is more predictable and uses hand-offs of work through a flow.

Using Sprints to manage complicated work results in batched work and an artificial division through sprint planning and review. It hides discipline inefficiencies and leads to split stores which create no value individually. Imagine the cost of buying a house if every one was a custom concept home built by a guild of craftspeople.

Using a Kanban to manage complex work results in turbulent flow that either creates inefficiencies and a lack of transparency or artificial deadlines to call things "done" when they really aren't.  Kanban doesn't handle the back-and-forth of exploration very well. This creates debt and can limit the creative potential of a game. It's why we don't use an assembly line to design a new car.

I often see Kanban used for complex work because there is still an "upfront planning" mindset that thinks a new uncertain game mechanic can be broken down into bite-sized discipline centric steps and pushed though the teams. Sprints are abandoned because the developers cannot be trusted to take larger goals and break down the work as they see fit.

Choose the best tool for the work.  Wielding a hammer with great skill to cut long pieces of wood into smaller ones isn't as useful as using a saw.
Categories: Blogs

SAFe 4.5 Goes Live: Top 5 Reasons to Update

Agile Product Owner - Wed, 06/21/2017 - 13:40

Hi Folks,

About 18 months ago, we launched SAFe 4.0, a major upgrade that delivered innovations for Lean software and systems engineering. It represented a major milestone of maturity for the Framework, and has enjoyed widespread popularity, including being named the #1 scaling framework by VersionOne’s State of Agile Report.

That tells us we were on the right track. But digital disruption is driving innovation at speeds we’ve never seen before, so while enterprises have been busy practicing SAFe, we’ve been busy making sure that the Framework continues to keep pace with emerging development and technology trends.

And so, today we are delighted to announce the release of SAFe 4.5! It’s a reflection of field research from hundreds of implementations, feedback from our customers and community, and new advances made in the knowledge pools upon which SAFe is built. As you learn more, we believe you’ll find 4.5 to be leaner, more Agile, and better at fostering faster innovation and learning than any of its predecessors.

SAFe’s name gets a makeover

We like to think of SAFe as a big tent framework that can accommodate any organization, regardless of size or complexity. As you know, SAFe isn’t just about IT, systems, and software. It’s part of a larger solution development picture, and we absolutely want to be sure that message is front and center for our internal and external business partners, as well as the community at large. So we’ve updated its name to reflect this more inclusive theme. The Framework is now known as SAFe for Lean Enterprises.

Top 5 Reasons to Update to SAFe 4.5

SAFe 4.5 delivers advancements in configurability, implementation guidance, and enhanced capabilities for improving the user experience and accelerating time-to-market. Below is a short summary of the primary enhancements to SAFe; for the in-depth view please refer to Whats New in SAFe 4.5.

  1. Additional flexibility with four new configurations: SAFe 4.5 supports the full range of development environments, from the simplest to the most complex. As the needs of the organization grow, SAFe is able to scale to meet those challenges. SAFe now comes with four out-of-box configurations, starting with ‘Essential SAFe,’ the entry point for organizations that want to start realizing the benefits as soon as possible. A click of the mouse will configure ‘Portfolio SAFe,’ adding portfolio-level concerns, including strategy and investment funding, Agile program guidance, and Lean governance to the picture. ‘Large Solution’ SAFe is for those building really big systems that take multiple Agile Release Trains and Suppliers to build. And finally ‘Full SAFe,’ for the larger enterprises that wants to achieve all the benefits of the truly Lean and Agile enterprise.
  2. Faster innovation with the Lean Startup Cycle and Lean UX : The integration of Lean startup practices and Lean UX in SAFe fosters an environment where investments start as a hypothesis in the form of a Minimum Viable Product (MVP), and feedback is introduced as early as possible to test ideas and make decisions more quickly. If the hypothesis plays out, additional features then make their way through the respective backlogs. If not, fast learning allows the business to pivot to a more desirable solution—and quickly.
  3. Accelerated new feature delivery with Scalable DevOps and Continuous Delivery Pipeline: Of course, you can’t likely get the feedback you need if you can’t move all those new ideas into production more quickly. To that end, the centerpiece of SAFe 4.5 is the integration of the Lean ‘hypothesis-build-measure-learn’ cycle with Scalable DevOps and a Continuous Delivery Pipeline. These new SAFe mechanisms enable the organization to continuously define and deliver solution elements to the end user, without large handoffs or excessive operations overhead. The result is a production environment that is able to deliver value more frequently, where hypotheses can be tested against their intended business outcomes, and where the deployed solution has both the flexibility and robustness needed to deliver more innovative solutions, far more quickly. You may well be a big enterprise, but you can innovate, and SAFe 4.5 can help show you how. 
  4. Improved guidance with the SAFe Implementation Roadmap: We can all admit that becoming a SAFe Lean-Agile enterprise is quite a journey, and a significant organizational change. To that end, we’ve provided new guidance in the form of a 12 article series, the ‘SAFe Implementation Roadmap.’ Based on proven organizational change management strategies and extensive field experience, the Roadmap describes the critical moves that an enterprise can take to achieve early wins and sustainable long-term gains with SAFe.
  5. SAFe 4.5 is fully backwards compatible. And finally, here’s some additional good news:  If you are already on a SAFe 4.0 journey, SAFe 4.5 is backwards compatible. All the features in 4.0 that you’ve come to depend on are still in place. You can adopt the advanced practices of SAFe 4.5 at your own pace, and derive the additional benefits without rocking the boat of your current implementation. 

Click here to get the full rundown of the new features.

In addition to the new 4.5 content, all the 4.0 articles have been updated as well, so there is much more to learn, and gain. For those of you who are certified, you’ll find a What’s New in SAFe 4.0 video on the SAFe Community Platform that will help you learn about the new features, and upgrade your certification so that you can support enterprises seeking SAFe 4.5 implementation.

SAFe Version 4.0 Available Through June, 2018

We encourage you to update to SAFe 4.5 to take advantage of the new features, but recognize that there are enterprises that will need the 4.0 version for some time to come. SAFe 4.0 will be supported throughout June, 2018, and remains available at v4.scaledagileframework.com.

Courseware Updates

Three courses from Scaled Agile’s role-based curriculum have been already updated to reflect the new features of SAFe 4.5. They include: Implementing SAFe, Leading SAFe, and SAFe for Teams. The remaining courses will be updated over the coming weeks.

It is our sincere hope that this new version helps you and your enterprise achieve the benefits you all deserve for working so hard at building the world’s biggest, and best, software and systems. 

We owe a special thanks to you, our SAFe community, for all your feedback and support. Your passion for the best SAFe possible has driven us to deliver what we like to think of as the most adaptable—and now configurable—framework in the world.

We do all this simply because ‘better systems make the world a better place.’

Stay SAFe!
—Dean, Richard, Inbar, and the entire team from Scaled Agile

Dean Leffingwell, Creator of SAFe, Chief Methodologist
Richard Knaster, SAFe Fellow and Principal Consultant
Inbar Oren, SAFe Fellow and Principal Consultant

Categories: Blogs

The Simple Leader: Reduce Information Overload

Evolving Excellence - Wed, 06/21/2017 - 10:47

This is an excerpt from The Simple Leader: Personal and Professional Leadership at the Nexus of Lean and Zen


Everybody gets so much information all day long that they lose their common sense.
– Gertrude Stein

Information overload is a big problem in modern society. We only have so much time and mental capacity to process information, and if we are not careful, the abundance can overwhelm us. We need to make it a priority to wisely manage the information-sharing systems at our companies, including email, phone calls, and voicemail.

Emails can be a big productivity killer if not managed properly. How many emails are in your inbox right now? If you’re like most people, you have dozens, perhaps hundreds. I know a couple folks who have over a thousand! What good is that? Having so many emails in your inbox will make you feel overwhelmed just by looking at it. How is that respecting yourself ?

I used to have more than a couple hundred emails in my inbox at any one time. When it got to be too many, I’d re-sort the inbox by sender and mass delete emails from people I considered to be a lower priority than others. Yes, I really did that. I was not exactly showing respect for people, let alone being mindful of the problems it could create for them and the organization.

This changed for me when a few years ago I came across a blog post touting “Inbox: Zero.” My reaction was, really? Zero emails in your inbox? Although I was skeptical, I gave it a try and haven’t looked back since. I can’t remember the last time I had more than ten emails in my inbox, and I try to get to zero by each evening.

To stay near or at Inbox: Zero takes effort and discipline, which needs to turn into habit. These are the steps to do it:

  1. Aggressively unsubscribe from newsletters and promotional emails, unless you are willing to read them within one day. With the ones that remain, move them to a “To Read” folder immediately, or send them there automatically via an email rule.
  2. Aggressively remove yourself from group distribution lists that are not critical.
  3. If you were just cc’d or bcc’d on an email, scan quickly and make every attempt to not reply, then delete. Ask the sender to remove you from the chain if your attention isn’t critical to the matter.
  4. Add (or decline) invitations to your calendar immediately.
    Be aggressive about declining if you don’t believe the meeting adds value—remember the Just Say No section above.
  5. Try to take action (or respond) to an email immediately whenever possible. Otherwise, move it to a “To-Do” folder. I’ve now become good enough at this that my inbox is my residual to-do folder, generally with less than five tasks to be completed. Many people say this is the worst use for an inbox, but with so few emails it works well.

I can’t describe how liberating this process is. Now, I can give far better attention to the few remaining emails I have and generate more thoughtful and focused responses while respecting the senders and their issues.

Beyond cleaning up your own inbox, you can also help create a better email culture within your organization. First, be very judicious about who is copied on emails, and insist others respect your time as well. An “FYI,” if truly needed in the first place, does not need to be sent to a broad audience—that’s generally more a “CYA” (cover your you-know-what). Second, insist that any desired action be very clearly stated in an email, right at the top. Third, be very concise with original and reply emails. I had a big problem with this, and was known as the king of the long- winded email. I continue to struggle with being too wordy, and have a goal to try to keep emails to three sentences or less.

There are other aspects to email management that help increase your productivity. For example, I try to only check email four times a day, keeping in line with the pomodoro method I described earlier. I hope to reduce that to three times next year. I turned off auto-checking on my phone so I don’t get disturbed with each new email. I also aggressively clear out old saved emails. They may not technically cost anything, and they are searchable history, but they still seem like clutter. I am now actually very close to not only Inbox: Zero, but also Mailbox: Zero!

While email is a known productivity killer, phone and voicemail can also create information overload, if not managed properly. I have never been a fan of using the phone, even though I know it is often a more effective and immediate communication tool than email. I prefer to receive an email so I can properly contemplate and formulate a response. Many organizations, such as Coca-Cola, are turning off their voicemail systems to push people to use email or live phone conversations.

Because of this, and because people know I’m not very good at responding to phone calls, I more regularly use voicemails. (If I did, I’d probably manage very similarly to my email inbox: aggressively filter, and respond immediately.) One thing about the voicemail system that I do love is that any incoming voicemails are also sent to my email inbox. There’s even a service that will auto- transcribe them into the email, so I don’t have to listen to the audio (plus, they are searchable). I know several people that like sending audio messages via email, but in my opinion, they are wasteful for the receiver, as they cannot be quickly scanned and searched. My friend Paul Akers uses them very effectively, but I know others that take two minutes to convey ten seconds of information—which isn’t respecting my time.

Regardless of how you accomplish it, reducing your information overload is very important if you want to be an effective leader. By taking steps to slim down the amount of information that reaches you, you will be able to be more effective with the tasks that truly need your time and attention.

Categories: Blogs

UnBoxing: Open Space Agility workshop

Agile Complexification Inverter - Wed, 06/21/2017 - 04:06
I'm taking Mezick's introduction course to OpenSpace Agility - thought I'd write a bit about what I'm learning.


Day One:
Beginning concepts - leaders have a duty to set direction and name constraints; yet stay away from telling how to achieve the goals.  Executives commits to holding first OpenSpace and Acting upon the proceedings.  And holding a second OpenSpace after a time box (100 days).

A constraining forces in OSA will be the Agile Manifesto, actions and experiments should be judged by this definition and if seen to support it, be considered good.

Another foundational concept of OSA - Self Management - defined as the behavior of a group to know and practice their decision making process (whatever that may be).  A good test is to ask 5 people how their group makes decisions - then count the number of answers - one general description of their decision making apparatus points strongly toward a self-managing team.

Q:  Many agilist are searching for a scaling framework.  If the foundations of agile mindset shift is a willingness to engage in dialogue about possibilities; how does one scale willingness?  Dan pointed to UX designer Micah Zimring candidly discusses his experience of the OpenSpace Agility process, including his initial skepticism going in. (Note: When you hear the the word ‘churn’ used in this interview, it means ‘lack of decision-making’ or ‘indecision’).

Paraphrasing Dan:  'Most Impediments come from:  People making decisions they do not have authority to make e.g. boundary issues with authority & decisions.'

 Harold highly recommended book:  Fierce Conversations by Susan Scott (better than Crucial Conversations - you say potato, I say pootato, let's check it out.)

Day Two:
There was a interesting conversation happening on the pre-meeting video conference... people engaged and communicating on a true personal level (acting with trust).  This is quite unusual for so many tech video conferences, regardless of team size, team maturity level, group dynamics.  I felt as if I'd entered an old familiar bar where everyone knew my name - Norm!

We might return to this concept... later...

So my notes say we might have started with a bit of a lesson on the distinction between some points on the influence spectrum.  After all many Agile "coaches" attempt to influence other people, many times they have great impact for the good (well at least that's how I get to sleep at night).  I may have ruined this one guy's whole sleep over... he joined our little band of developers in Seattle and got along well, we learned to develop working tested software, and to the direction of a great PO.  She had the vision to lead us on a journey - there was some unknown territory along the way - and we discovered the reasons for some weird missions.  Later this guy wrote on a discussion thread about the woes of the good old days - that he'd rather not work on Agile projects any more, because he knows from experience what it can be, what it should be, ... but the project are not that.  It's lipstick on a pig.  He'd rather do waterfall projects.  Because coding to the spec is easy, no work at all really.  However playing the in-between game is hell.

Oh - sorry - that crap just jumped out of my fingers... we were talking about influence - all the way down the slippery slope to manipulation and into coercion.  Now I can not define these term - now after two beers ... and it's just going to get worse as I type and imbibe.  So look it up your self if you don't have a good feeling of the continuum we are discussion.  Do you agree these are on the same dimension?

When does one cross the invisible line from influence to manipulation?  Does it matter... if the ends justify the means?  Dan suggested a way to view manipulation - I'd never heard it explained so well.  I've always considered manipulation as influence in the eyes of the influencer, while being manipulation in the eye of the beholder.  Dan defined manipulation as something you realized happened four hours ago.

What's this got to do with OSA?  Turns out it is a foundational principle of OpenSpace.  The aspect of having freedom and agency to make a decision to participate.  Show of hands - who has been informed by the leaders that they were going to now start practicing this Scrum process, and these coaches were here to help you?  All the hands go up.  Who has been invited to be part of an Agile Transformation?  Two hands only.  Which set of people have been influenced?  Which set have been manipulated?  How does this effect the long term commitment to a "transformation"?

Topic Jump to Meetings - what is the generic structure of a meeting:

  • Goal
  • Rules
  • Progress
  • Participation

Going into detail on these...  but let's just focus upon Progress - how's it measured?  Maybe in most meeting by the clock hands.  Sometimes by agenda items checked off.   Are those items classified into one of a few groups:  discussion, decision, information dissemination, a waste of time.

Participation - is your meeting an Opt-In meeting or an attendance required (with unknown consequences to be determined later by the boss) meeting?  Perhaps making this explicit would be helpful in an organization of more than 5 people.  At the heart of OSA - the invitation (Opt-In) format of the events.

So how does a meeting differ from a Game?  Is there any real difference?  Fun... oh yes!  Why is fun not an emergent outcome of meetings?  Games have this very same structure.

Games and meetings have these aspects as well as structure:

  • Control
  • Progress
  • Belonging

One big difference in games and poorly held meetings is the visual depiction of progress.  In beginner games (Candy Land) the board is the indicator of progress.  It takes very little synthesis to determine who is progressing well in the game.  Chess is quite different.  How are your meetings progressing?  What visual indicator of progress do you include for the people?  Do they become motivated or demotivated by seeing progress made toward a goal?

Why are most games perfectly well run with player participation and no umpire or referee?  Is it the well understood mental model of the rules and proper behavior on the field of play?  What would happen if meetings had these rules?  Do they have rules?  Where's your meeting rule book?

Topic transition to Leadership concerns for OSA.

Sponsor understanding their role and what is about to happen (maybe they feel out of control).
 - development of theme (together, maybe a group)
 - invitation development (come finish the story with us)
Sponsor must communicate:
 - explore the theme & contribute to proceeding (artifact)
 - suspend disbelief for the duration of experiment (100 day trial)
 - invited to the post-experiment Open Space (in 100 days)

Book:  Leader's Guide to Store telling - Steve Denning

Leaders are constantly signaling - ever micro expression gets a mean assigned by followers constantly watching - no rest for the leader - never off stage, the mic is alway HOT.

Story telling is a signaling event with a bull horn.

Book:  https://mitpress.mit.edu/books/honest-signals by Alex Pentland - MIT

Emergent Leadership is like musical chairs.  People change their minds during the game; they may be motivated to move quickly to acquire a seat (at the table), to contribute to the outcome of the story we write to become our future selves.  Open Space encourages people to get a chair.

OpenSpace is a game about authorizing and authority - who has it, who is giving it, who is receding it, etc.  It is played out in a high frequency feedback space of face to face - full body contact - interactive group dynamic.  It is full of potential energy - release it.

Open Space is an Authorizing Function over the time domain of the event.

People authorize others to contribute to the shared understanding, by giving their time and attention to the speaker.  Because they are also free to seek more value if they deem the speakers value lower than opportunity cost.

Day Three:

We started the lesson with the topic of Leadership Prep - the admonishment was to "eat our own dog food" - to open space for the leader to learn about OSA to experiment with safe to fail experiments, to inspect the results and adapt to the needs of the leaders to grow in their understanding of the Open Space.  Search softly for the leader's maximum skin they will put into the game,  cut that in half and practice.  It is this experience (safe to fail) that will lead to understanding - it may be the only way for mere mortals to catch a glimpse of the philosopher's stone inside of the Open Space onion skin of powerful technology.

At some point Harold explained the inside joke of the term Technology in OST... perhaps it's useful in the simplicity of it's inverse, in it's sarcastic usage...  OpenSpace Technology requires the very first and hardest to understand technology that humanoids developed - language skills.

Warning:  Do NOT lead with an unacceptable invitation.  This was Dan's advice, and other's echoed it.  The advice seemed to come from a deep desire to short cut our journey toward successful engagements with clients.  With an action step of starting small, almost imperceivable - don't mention OSA at all - just encourage the leader to make a meeting optional.  A true Opt-In event, with the power of invitation and no repercussion for checking out.  See what the leaders can discover in the behaviors of the people - are they following - are they happily engaged - are they curious - who's participating - who's willing and able to change behaviors?

Another experiment (a few steps up the ladder) - Dan calls it an "A1" meeting.

Look up. B. J. Fogg - Persuasion Lab - I can't remember why - guess I wasn't persuaded.

We spent a bit of time discussing and practicing non-verbale signaling.  A suggested resource: The nonVerbal Dictionary.  Do you read body language?  If not you may be well toward one side of the autism spectrum.  Most everyone does read body language quite well, we've been doing it since very early - I think I heard a story that infants can read facial patterns.

Look into Powerpoint karaoke - a great team game.

Topic of Organizational Learning (time to get your Senge on).

What impedes org learning - fear. When a human is afraid the Neo-cortext is not being engaged, and the monkey mind is getting all the blood flow, this severally limits learning.

What can we do to counter act the stimulus-response mechanism over which we have little immediate control? Create physiological safety... yeah, but how? Well maybe a lesson for another time - but for sure this is a learning enabler. To check this out - watch small kids on the playground. Playing is learning. When play stops - what happened?

Topic of Informal Authorization. How do we recognize this form of authorization? It's communicated constantly, learn to sense it... it's not on a sign post, or in a sound wave - yet it is all around you. Tune into the signal, learn to amplify it, to dampen it and to withdraw informal authorization. It is a powerful force - recognize who is using this, and who is oblivious.

Review: Invitation has: clear goal, rules or constraints, a way to experience progress toward goal, an opt-in participation.

Challenges (Opt-in homework):

Invitation: What are the most simple invitations (with 4 aspects) that we can generate?

Spark some invitation experiences: Issue 3 or more invitations this week.

Read Sprit by Harrison Owen PDF - search for number of occurrences of "open space" vs "Open Space" investigate usage and content - what was he signaling?

Well expect to be surprised: Harrison Owen showed up on the conference call to share some space with our group.

Harrison Owen - discover/giver of Open Space Technology
Here are some badly paraphrased quotes from Harrison:

I have a suspicion or a conviction that:
  • life is self organizing; so, what is a manager for?
  • self organization does the best job; are we stupid to use management techniques?
"Since the universe has been practicing for 13 billion years on self-organizing principles - its not really about improving self organization; but how do we optimize self-organization to enable people?"

Read his book:  Wave Rider

Peter _____ studying behavioral characteristics with performant systems - they have zero regard for external authority.  From scale of micro <--> cosmic.  This group self-organization principle appears to hold true.  Discipline with respect to self organization phenomena :: forcing people to do something that doesn't work for them ... is counter to system goals in long run.  Distinguish between external / internal discipline :: bad / good.

Example traditional education techniques rely upon discipline - it's a destructive force.  Learning is play - Learning is a self organizational system a phenomena with a virtuous cycle.

Day Four:

Question:  what's up with this core protocol: Check in/Check Out process?
A: it's a subtle little hack - about getting a small agreement to communicate and engage.
One might also find info in Influence books topics.

Question: Harrison Owen spoke of "sitting in the Question" - what's that about?
A: not knowing - be OK in that space.
One might also find solace in Donald Rumsfeld's "There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don't know. But there are also unknown unknowns. There are things we don't know we don't know."
- hummm... or NOT!

Liminality - participants "stand at the threshold" between their previous way of structuring their identity, time, or community, and a new way, which the ritual establishes.
Learning is CHANGE - it is hard to un-learn :: therefore hard to change.  Many people will make up myths to avoid uncertainty and worry - be very very careful who is allowed to create the myths of your organization.  If the leader's are not telling stories - the vacuum of story telling will be filled - by someone.
From Ritual to Theater - Victor Turner - The Human Seriousness of Play
One may think of OpenSpace as a study in authorization - imagine that one could easily and without malice deAuthorize a colleague that was advocating for a position or path that you disagree with.  In OpenSpace this should be relativity easy - see the Law of Two Feet.
Some Wisdom & Warnings:
The Proceedings - one may think the sponsor will do everything suggested in the proceeding and that the sponsor will be responsible for carrying it out - think again.
Watch out for a sponsor that said YES easily.  (But action show them as meaning NO.)
Learning is fundamentally destabilizing - a sponsor or leadership that needs stability might not be ready for a group of subordinates that are ready to learn (make mistakes and attempt new risky behaviors).
If you are actively coaching the Org or leadership; do NOT facilitate the OpenSpace - pass the authority - it will benefit the organization and in the end, you also.

----post workshop:  I attended a one day "open space" styled conference and saw that I had learned quite a bit in Dan's sessions.  Knowledge is like magic.

See Also:
Ted Talk on the use of texture in architecture and the effects upon people in public spaces.
https://www.ted.com/talks/justin_davidson_why_shiny_glass_towers_are_bad_for_city_life

Check out the OpenSpace Agility site.  From the about page:
OpenSpace Agility (OSA) is a repeatable technique for getting a rapid and lasting Agile adoption. It works with what you are currently doing, and can be added at any time. For executive leaders, OSA is a template that operationalizes the core values of Lean, namely: respect for people, and continuous improvement. For executives who are truly committed to these values, OSA represents a simple, effective and very efficient way forward. With OpenSpace Agility, you can expect:
  • A dramatic reduction in the coaching & training costs of implementing your Agile program
  • A genuine, rapid and lasting Agile transformation
  • A dramatic increase in employee engagement scores
  • A dramatic increase in stakeholder satisfaction and potentially, genuine stakeholder delight
  • Predictable, reliable, repeatable, EVIDENCE-BASED improvement in overall results
OpenSpaceAgility incorporates the power of invitation, Open Space, game mechanics, leadership storytelling and more…so your Agile adoption can actually take root. OSA is based on people, THEN practices. You can use any practice or framework with OSA: Scrum, Kanban, DaD, SAFe, LeSS, and more.
Categories: Blogs

The Digital Platform - resurrection of the Hub Strategy

Agile Complexification Inverter - Wed, 06/21/2017 - 03:17
There's a lot of talk these days in the tech sector about "digital _________" or a "______ Platform" - have you noticed it also?  I find this astonishing, as the world turned digital back in the 1980s along with disco.  And as for platform - well adding the word to shoes was a bad idea back then also.

So what causes this echo from the past?

I don't know - shall we investigate this over the next few months - the dog days of summer 2017?

Summer is a season.  Season are cyclical - they come around again and again.  So this brings us to ponder... When do the days get longer and why?  Most people answer Summer.  And what's the longest day of the year (Northern Hemisphere)?  Right June 20th, the summer solstice.  And so the next few days the daylight is getting less and less - all summer long the days get shorter and shorter.  Almost completely backwards from what we thought we knew.


Do you remember way back in 2001... when Steve Jobs laid out Apples Digital Platform - called the Hub Strategy?
"The Mac," Jobs said, "can become the 'digital hub' of our emerging digital lifestyle, adding tremendous value to our other digital devices.""Jobs laid out a path of PC evolution that defined the early 80s as an initial 'golden age' of computing based on productivity software, which began to wane in the early 90s. A 'second golden age' began in the mid-1990s with the rise of Internet; but it too began to lose its momentum by 2000. Jobs said he believed a third age would focus on a digital lifestyle, driven by an 'explosion of digital devices.'"

-- by Phil Simon The Age of the Platform


Steve Jobs introduces the "Digital Hub... by HiltonRobb


Simon writes "Apple forced this third golden age by developing its platform -- and making it so compelling to use." To see the ecosystem of the computer as a hub of your digital life. They have executed on that vision with the iPod, then the iTunes store, the iPhone and the App store, now the iPad and the iBookStore. Are we following a pattern, is there a cookbook? The leader has a vision, shares the vision with the followers, the followers buy into the vision and together make it a reality. 

The new product adoptions phases are progressing quite nicely. Apple is a master at this process, described by David Pogue in: http://pogue.blogs.nytimes.com/2010/01/27/the-apple-ipad-first-impressions/.


Wildly Successful New Product Launch Phases:
  • Phase 1 feverish speculation and hype (preannouncment)
  • Phase 2 disappointment and bashing (prerelease)
  • Phase 3 attainment anticipation and adoration (post release)

See Also:

Why Tim Cook is Steve Ballmer and Why He Still Has His Job at Apple by Steve Blank"What happens to a company when a visionary CEO is gone? Most often innovation dies and the company coasts for years on momentum and its brand. Rarely does it regain its former glory."

Categories: Blogs

Who’s Afraid of Emergent Design?

Leading Agile - Mike Cottmeyer - Tue, 06/20/2017 - 21:39

A hallmark of lightweight software development methods is the notion of emergent design. The idea is that the design of the solution will emerge little by little as we build up the code in small increments, typically using test-driven development with very short red-green-refactor cycles.

When it goes well, we avoid a number of problems. We won’t create a comprehensive design and write a lot of code that only leads us down a rabbit hole that’s hard to climb back out of. We won’t get carried away with our natural creativity and over-engineer the thing way beyond what our customers want to pay for. We won’t end up with a suboptimal architecture because we invested too much too soon in our initial design ideas.

It’s a simple enough idea in principle. It really isn’t difficult in practice, either; I can vouch for the fact it makes the work considerably less stressful and more enjoyable than the Old Ways of building applications.

And yet…

Have you ever tried to push the north poles of two magnets together? The magnets get close, and then slide apart. Each time they slide apart, it’s in a different direction than the time before.

When working with developers who are unaccustomed to emergent design, I sometimes get the same feeling. They seem to understand the concept, and they seem to be getting really close to doing it, and then it slips away from them.

Why so much difficulty? Well, as the saying goes, the devil is in the details.

Where’s the safety net?

If you’ve always worked from a comprehensive, detailed design specification, then starting to code with anything less than that is going to feel pretty uncomfortable. What if you forget something important? How can you be sure the design that emerges will be any good? Lacking detailed design specifications, how will you know whether a proposed code change will affect other parts of the solution?

It feels like you’re crossing a half-frozen river by leaping from ice floe to ice floe. That design documentation was your safety net for changing the code. Now, what are you supposed to do?

Actually, you do have a safety net, and it’s far more trustworthy than any design document. Remember that we use the technique known as test-driven development for emergent design. Those executable test cases accurately and fully describe the low-level behavior of every unit of code in the solution. They are always up to date with respect to the production code, however little or however much of it there is on any given day. Driving every new feature, every modification, and every bug-fix from tests gives you a high degree of protection from errors.

Nothing is foolproof, of course, and like anything else we do in our work, test-driven development is a learned skill that requires practice. But that’s nothing new for you. After all, you weren’t born knowing all the things you know how to do. You had to learn them. All of them. This is just One More Thing. And it’s easier than most of the other things you’ve learned about software development over the years. (See? I told you it was less stressful!)

Just enough design initially

Developers who are just beginning to learn emergent design often hold a certain misconception at first. They think “emergent design” means “no design at all.” You just open up your favorite editor and start typing. That’s not quite right.

There’s an old mantra that (I think) came from the Feature Driven Development community years ago: Just Enough Design Initially (JEDI). To take an emergent approach to solution design, JEDI is our starting point. There’s a lot of territory between comprehensive, detailed up-front design and no design at all. It’s incumbent on us as professionals to be able to make judgments about where, in all that territory, we should begin any given project. It isn’t always the same spot.

Well, if JEDI means different things in different situations, then how are we expected to learn to make judgments about it? The bad news is there are no hard-and-fast rules. The good news is there are no hard-and-fast rules. We get to use our intelligence, creativity, training, and experience, and we get to collaborate with other smart, creative people, rather than just coding to someone else’s spec. (See? I told you it was more enjoyable!)

Architectural design or application design?

I find it useful to draw a distinction between architectural design and application design. Most of the time, when we write a new application we aren’t simultaneously inventing the architecture that supports it. The architecture is like scaffolding on which applications can hang. Yet, many people think it’s mandatory to begin each project by designing the architecture for the solution.

As long as our application is a new instance of an existing type of thing, we don’t need to begin our work with an architectural design. There’s already an architecture, if not several architectures, relevant to our new application. “Just enough” up-front design is probably not very much.

Sometimes, if we’re lucky, we get to build an entirely new type of thing. There’s no existing architecture on which to hang it. In this case, “just enough” up-front design amounts to more than in the first case…but you still might not do a comprehensive design up front, as there’s value in emerging the architectural design, as well, once you get to a good starting point.

We aren’t necessarily starting completely from scratch when we build an application. There may be reference architectures, design patterns, libraries, code generators, and other resources available to save us time and effort. You don’t need to design an architecture to support a new web app. You can choose from Model 2 or MVC, Hierarchical, and Single-Page architectural patterns. You don’t need to design a responsive web app from scratch; you can choose a web app framework that has responsive design built in already. You don’t need to design an architecture for a mainframe batch process that grinds up sequential files all night. You already know it must comprise a subset of extract, sort/merge, edit, update, and report steps. These are well-known types of things, and once you’ve seen an example or two, you never need to re-design one from whole cloth.

The basic advice here is: Don’t reinvent the wheel.

Your past experience counts as up-front design for your next project

I don’t recall where I first read or heard that saying. I didn’t make it up, but I like it. Your new application isn’t identical to any existing application. After all, if it were, then you wouldn’t need to write it at all. But at the same time, the new application probably isn’t so very different from other work you’ve done in the past.

Do you really need to re-draw all the design diagrams you drew on those past projects? I’ll bet you don’t. You’re just checking a box on a checklist of tasks: “Draw design diagrams.” I’ll bet if you drew those diagrams, you’d never look at them again. After all, you didn’t the last 25 times you drew them, now did you? Come on, ‘fess up!

Don’t do anything stupid on purpose

That’s another one of my favorite old sayings. It’s been common among engineers for decades. Signs hang on the walls of labs bearing those inspiring words. All those software design principles folks like us are always jabbering about can be derived from that single ur-principle: Don’t do anything stupid on purpose.

Sometimes, when developers are first trying to apply the idea of emergent design, they very strictly follow the (intentionally)-incomplete and -lightweight specifications to the letter. That is, they don’t do anything that isn’t explicitly specified.

And that violates the ur-principle. You know your application has to handle exceptions gracefully. You know it has to support logging. You know it (probably) has to support internationalization, accessibility, and a host of other things that most or all applications have to do. Do you really need someone to write that stuff down for you every single time? You know the drill.

So, who’s afraid of emergent design? Not you.

The post Who’s Afraid of Emergent Design? appeared first on LeadingAgile.

Categories: Blogs

New Case Study: SAFe helps Fitbit Increase velocity by 33%

Agile Product Owner - Mon, 06/19/2017 - 21:04

SAFe has been a successful story for us. It allowed us to grow our team in a seamless way that integrated cross-functional groups and aligned with the company’s long-term strategy. Fitbit has grown significantly since we adopted SAFe, and we were able to scale the process and still deliver high achievement every PI. My VP calls it the scaffolding that has helped move our team forward.”
Damian Brown, Sr. Director of Program Management Office, Fitbit

Our latest case study comes from the consumer technology market, where the pressure is on to release products ahead of major shopping events such as the year-end holiday season, Valentine’s Day, graduation, and Mother’s and Father’s Days.

At Fitbit, the challenge of meeting those targets had increased along with the company’s growth, and their Scrum efforts were not effectively scaling to meet the needs of the business and their global community of users. But in the past year, Fitbit was able to make major progress on the cadence and velocity of its development:

  • Last year, Fitbit released four new products that were positively received by consumers—a record number for the company
  • Teams now achieve five business goals per PI, on average, compared to three previously
  • Velocity increased 33 percent year over year
  • The company experienced no major impact to their website during the critical high-sales time-frame between Black Friday and the New Year
  • As for visibility, Fitbit achieved a long-term look-ahead on its product roadmap and a short-term execution plan, supporting planning and decision-making for leadership.

How did Fitbit achieve all these milestones? The company deployed SAFe in the fall of 2015. Damian Brown and Brian Hsieh at Fitbit had both seen SAFe successfully deployed at a previous company and believed it could work at Fitbit. After gaining executive buy-in, the company started with 12 Scrum teams for Program Increment planning in San Francisco.

With each PI—now up to 10—Fitbit folded in more teams and more functional business groups, including some not typically part of an Agile transformation: Firmware, Software, Design, Research, Marketing, Customer Support, Data Analytics, and Infrastructure Engineering all participate in PIs. To increase the chance of success, Fitbit trained all those who were leading PI events across multiple office locations.

With the help of SAFe, Fitbit evolved its process. It now has a faster and more flexible flow across the ecosystem, smoother scaling, improved visibility, and greater alignment across all programs.

And with higher cadence and velocity, Fitbit can more readily respond to market needs. For example, when the company noticed an opportunity to add a specific capability to its products, it brought the new feature to market in a very short time with no major bugs in internal and external testing.

Now, as the company plans for next year, it’s working toward funding value streams rather than projects.

Check out the full case study.

Many thanks to Damian Brown, Sr. Director of Program Management Office; and Brian Hsieh, Manager of Program Management Office, for sharing Fitbit’s story.

Stay SAFe,
—Dean

Categories: Blogs

Defining “Scaling” Agile, Part 6: Creating the Agile Organization

Johanna Rothman - Mon, 06/19/2017 - 16:30

We might start to think about agile approaches as a project change. However, if you want to “scale” agile, the entire culture changes. Here is a list of the series and how everything changes the organization’s culture:

All of these “scaling” ideas require change.

Agile organizations become very good at small changes all the time. They are adaptive and resilient. They understand how change works and they embrace it. (Big changes are quite difficult for almost everyone. Small changes tend to be much easier.)

Here is a picture of the Satir change model. We start off in Old Status Quo with some level of performance. Some Foreign Element arrives and we have uneven performance while we are in Chaos, searching for that Transforming Idea. We discover that TI and practice and integrate that idea into our work until we reach a New Status Quo, hopefully at a higher level of performance.

The change model works for each human and for the entire organization. In fact, I don’t see how you can have an agile organization until people become comfortable with small and large changes on a regular basis. This is one of the reasons I say we should take an agile approach to agile. (See Agile is Not a Silver Bullet.)

Do you need to be a fully adaptive and resilient organization? Only you can answer that question. Maybe you start from teams and the project portfolio. Maybe you look for incentives that don’t create optimization “up.” (I need a new word for this! Do you have suggestions for me?? Please comment if so.)

You do not have to have a fully agile organization to recognize benefits at the team and project portfolio levels. Agile is Not for Everyone.

Decide how much change your organization needs to be successful. Practice change, as often as you can. That will help you more than an agile label will.

One last comment: I’m not sure “scaling” is the right way to think about this. For me, the scaling idea still has roots in silo thinking, not flow thinking. That could be just me. (Grin!) I wish I had a better way to explain it.

My ideas of scaling agile are about creating a culture based on our ability to change:

  • How do we treat each other? Do we/can we see each other as an intrinsic part of a whole?
  • What do we discuss? Do we discuss “failures” or learning opportunities?
  • What do we reward? How do we move to rewarding non-silo work? That is, work to deliver products (in either projects or programs) or other work that rewards collaboration and flow efficiency.

I hope you enjoyed this series. Please do comment on any of the posts. I am curious about what you think. I will learn from your comments.

Categories: Blogs

New Case Study: SAFe helps Fitbit Increase velocity by 33%

Agile Product Owner - Mon, 06/19/2017 - 16:04

SAFe has been a successful story for us. It allowed us to grow our team in a seamless way that integrated cross-functional groups and aligned with the company’s long-term strategy. Fitbit has grown significantly since we adopted SAFe, and we were able to scale the process and still deliver high achievement every PI. My VP calls it the scaffolding that has helped move our team forward.”
Damian Brown, Sr. Director of Program Management Office, Fitbit

Our latest case study comes from the consumer technology market, where the pressure is on to release products ahead of major shopping events such as the year-end holiday season, Valentine’s Day, graduation, and Mother’s and Father’s Days.

At Fitbit, the challenge of meeting those targets had increased along with the company’s growth, and their Scrum efforts were not effectively scaling to meet the needs of the business and their global community of users. But in the past year, Fitbit was able to make major progress on the cadence and velocity of its development:

  • Last year, Fitbit released four new products that were positively received by consumers—a record number for the company
  • Teams now achieve five business goals per PI, on average, compared to three previously
  • Velocity increased 33 percent year over year
  • The company experienced no major impact to their website during the critical high-sales time-frame between Black Friday and the New Year
  • As for visibility, Fitbit achieved a long-term look-ahead on its product roadmap and a short-term execution plan, supporting planning and decision-making for leadership.

How did Fitbit achieve all these milestones? The company deployed SAFe in the fall of 2015. Damian Brown and Brian Hsieh at Fitbit had both seen SAFe successfully deployed at a previous company and believed it could work at Fitbit. After gaining executive buy-in, the company started with 12 Scrum teams for Program Increment planning in San Francisco.

With each PI—now up to 10—Fitbit folded in more teams and more functional business groups, including some not typically part of an Agile transformation: Firmware, Software, Design, Research, Marketing, Customer Support, Data Analytics, and Infrastructure Engineering all participate in PIs. To increase the chance of success, Fitbit trained all those who were leading PI events across multiple office locations.

With the help of SAFe, Fitbit evolved its process. It now has a faster and more flexible flow across the ecosystem, smoother scaling, improved visibility, and greater alignment across all programs.

And with higher cadence and velocity, Fitbit can more readily respond to market needs. For example, when the company noticed an opportunity to add a specific capability to its products, it brought the new feature to market in a very short time with no major bugs in internal and external testing.

Now, as the company plans for next year, it’s working toward funding value streams rather than projects.

Check out the full case study.

Many thanks to Damian Brown, Sr. Director of Program Management Office; and Brian Hsieh, Manager of Program Management Office, for sharing Fitbit’s story.

Stay SAFe,
—Dean

Categories: Blogs

The Simple Leader: Envision the Future State

Evolving Excellence - Sun, 06/18/2017 - 10:45

This is an excerpt from The Simple Leader: Personal and Professional Leadership at the Nexus of Lean and Zen


If you don’t know where you are going, you’ll end up someplace else.
– Yogi Berra

So now you have defined your principles, your why? (purpose), and your mission, and you’ve thoroughly analyzed the current state of your organization, process, or even you. It’s time to look into the future. This is exciting as you get to dream and be creative!

Based on your why?, what would the ideal future state of your organization, process, or yourself look like? Think toward the long term, perhaps a very long term. What would happen if there were no constraints? What would your metrics be? What new business segments or technologies should you bring online to grow or to mitigate risk? What does your team and employees look like in terms of function and capability?

You could look at other organizations for ideas, but be very careful with benchmarking. Simply adopting someone else’s best practice usually doesn’t work. Every organization’s context, perspective, goals, capabilities, and values are different.

Another way to look at a potential future state is to consider what perfection would look like. If your goal is perfection, then some other organization’s best practice may seem like a mere stepping stone. Thinking about perfection as a possibility can radically change your perspective. Finally, once again, think about you. Where would you like to be—physically, mentally, spiritually, and emotionally—in ten or more years? Document this future state, just like you did for the current state.

Now compare the current and future state documents. Where are the gaps? What are the priorities of the gaps? Which are the most critical to your survival? Which have the most promise? Which are low hanging fruit that can be bridged quickly? Does the future state still align with your principles, why?, and mission? Do all of the stakeholders agree? After going through this process and answering these questions, you should have a defined future state document, showing prioritized gaps and opportunities.

Categories: Blogs

Friendly Guide to Climate Change (and what you can do about it)

Henrik Kniberg's blog - Fri, 06/16/2017 - 20:17

I’ve spent ALOT of time the past few months trying to understand climate change and global warming, and how to effectively contribute. I’ve dug through 1000-page scientific reports, talked to experts, and basically tried to digest as much information as possible. I was surprised by how little I knew before. I’m convinced that, the more people who really understand the problem, the more effectively we’ll be able to solve it (or at least mitigate it).

So here’s a short animated video summarizing the whole issue. The problem, the consequence, the root cause, the solutions, and what you can do to help. All packaged in a fun and easy-to-digest way, same style as my other videos about Spotify Engineering Culture and Agile Product Ownership. The video is all based on solid scientific references, not speculation or rumours.

Please help spread it as widely as possible! Link to this blog post, or the youtube link: https://youtu.be/3CM_KkDuzGQ

I hope this video will inspire many people to make small changes, and a few people to make big changes. Who knows, maybe the next young Elon Musk is out there somewhere, just waiting for the spark of inspiration

Categories: Blogs

Unless these three things exist, your organization will always struggle to adopt agile.

Leading Agile - Mike Cottmeyer - Fri, 06/16/2017 - 19:05

Backlogs, Teams, and Working Tested Software are the fundamental preconditions that must exist for an organization to be able to do agile well. In agile these three things have very specific meanings. Compromising on the quality of the backlog, the completeness of the team or the definition of working tested software always decreases agility.

Backlogs

Most organizations underestimate the amount of time and energy it takes to create backlogs with the needed level of granularity.

  • User stories written in a consistent format
  • 1-3 days in size
  • Agreement on method of collaboration
Teams

Teams that don’t stay together and aren’t able to get to a definition of done stop believing they can and will never stabilize velocity.

  • 6-8 People
  • Work together side by side
  • Swarm to develop solutions
  • Has the ability to produce what is in the backlog.
Working Tested Software
  • Have to know what done looks like
  • Need to be able to get to done by the end of the sprint.

The post Unless these three things exist, your organization will always struggle to adopt agile. appeared first on LeadingAgile.

Categories: Blogs

scikit-learn: Random forests – Feature Importance

Mark Needham - Fri, 06/16/2017 - 07:55

As I mentioned in a blog post a couple of weeks ago, I’ve been playing around with the Kaggle House Prices competition and the most recent thing I tried was training a random forest regressor.

Unfortunately, although it gave me better results locally it got a worse score on the unseen data, which I figured meant I’d overfitted the model.

I wasn’t really sure how to work out if that theory was true or not, but by chance I was reading Chris Albon’s blog and found a post where he explains how to inspect the importance of every feature in a random forest. Just what I needed!

Stealing from Chris’ post I wrote the following code to work out the feature importance for my dataset:

Prerequisites
import numpy as np
import pandas as pd

from sklearn.ensemble import RandomForestRegressor
from sklearn.model_selection import train_test_split

# We'll use this library to make the display pretty
from tabulate import tabulate
Load Data
train = pd.read_csv('train.csv')

# the model can only handle numeric values so filter out the rest
data = train.select_dtypes(include=[np.number]).interpolate().dropna()
Split train/test sets
y = train.SalePrice
X = data.drop(["SalePrice", "Id"], axis=1)
X_train, X_test, y_train, y_test = train_test_split(X, y, random_state=42, test_size=.33)
Train model
clf = RandomForestRegressor(n_jobs=2, n_estimators=1000)
model = clf.fit(X_train, y_train)
Feature Importance
headers = ["name", "score"]
values = sorted(zip(X_train.columns, model.feature_importances_), key=lambda x: x[1] * -1)
print(tabulate(values, headers, tablefmt="plain"))
name                 score
OverallQual    0.553829
GrLivArea      0.131
BsmtFinSF1     0.0374779
TotalBsmtSF    0.0372076
1stFlrSF       0.0321814
GarageCars     0.0226189
GarageArea     0.0215719
LotArea        0.0214979
YearBuilt      0.0184556
2ndFlrSF       0.0127248
YearRemodAdd   0.0126581
WoodDeckSF     0.0108077
OpenPorchSF    0.00945239
LotFrontage    0.00873811
TotRmsAbvGrd   0.00803121
GarageYrBlt    0.00760442
BsmtUnfSF      0.00715158
MasVnrArea     0.00680341
ScreenPorch    0.00618797
Fireplaces     0.00521741
OverallCond    0.00487722
MoSold         0.00461165
MSSubClass     0.00458496
BedroomAbvGr   0.00253031
FullBath       0.0024245
YrSold         0.00211638
HalfBath       0.0014954
KitchenAbvGr   0.00140786
BsmtFullBath   0.00137335
BsmtFinSF2     0.00107147
EnclosedPorch  0.000951266
3SsnPorch      0.000501238
PoolArea       0.000261668
LowQualFinSF   0.000241304
BsmtHalfBath   0.000179506
MiscVal        0.000154799

So OverallQual is quite a good predictor but then there’s a steep fall to GrLivArea before things really tail off after WoodDeckSF.

I think this is telling us that a lot of these features aren’t useful at all and can be removed from the model. There are also a bunch of categorical/factor variables that have been stripped out of the model but might be predictive of the house price.

These are the next things I’m going to explore:

  • Make the categorical variables numeric (perhaps by using one hot encoding for some of them)
  • Remove the most predictive features and build a model that only uses the other features

The post scikit-learn: Random forests – Feature Importance appeared first on Mark Needham.

Categories: Blogs

Defining “Scaling” Agile, Part 5: Agile Management

Johanna Rothman - Thu, 06/15/2017 - 18:15

One of the challenges I see in organizations is how managers can use agile approaches. One of the biggest problems is that the entire organization is organized for resource efficiency (think silos of functional experts). Agile approaches use flow efficiency. Thinking in flow efficiency changes everything.

Many people in organizations believe that dividing up the work among specialists will get the work done faster. That’s the case in manufacturing. (Think piece work.) Manufacturing processes use resource efficiency to reasonable effect. However, manufacturing does not account for innovation or learning. (Design of manufacturing processes is innovative and requires learning. That’s why manufacturing processes often prototype (iterate on their work) when they develop the process.)

Organizations who need to optimize for innovation or learning realize that the people work collaboratively. Collaborative work—including management work—demands flow efficiency instead of resource efficiency.

Flow efficiency helps people optimize “up” for lack of a better term. (If you have not yet read This is Lean: Resolving the Efficiency Paradox, I recommend you  do so.)

Once you start to think about flow efficiency, you might start to think about throughput (and maybe cycle time and cumulative flow).  That changes the data the managers need to make decisions.

Now, it doesn’t matter what anyone’s utilization is. What matters is the Cost of Delay (or Cost of Delay/Duration). It might even matter where the bottlenecks are and who can unwedge those bottlenecks.

An organization might still need to track the run rate for a project, program, or even a workgroup such as Customer Support. Run rate might not mean as much when you can measure revenue, customer acquisition and retention, and how often you can get the customer to return and buy more. (The more often you deliver value, the more you can acquire customers who pay.)

One manager learned about flow efficiency. She was managing the team working on the “most important” project in the company. She decided to stop tracking utilization. She told her team, “I want to track your throughput as a team. I want to know what I can do improve the flow of work through your team. Please bring me your impediments to flow and I’ll address them.”

The team told her about build time (too slow), insufficient test automation (not enough and too slow). She built the case using Cost of Delay/Duration to get other teams to help this team reduce build time and increase test automation.

The teams together took eight weeks to make what they called infrastructure improvements. After the first two of those eight weeks, the team finished twice as many stories (2 instead of 1) as they had before all the improvements started. The team continued to increase their throughput. By the end of the eight weeks, the team was able to finish anywhere from 8-12 stories. The team continued their now-higher level of throughput. After three months, the organization had attracted many more customers. They decided to move to a subscription model for their product, and recognize much more revenue.

Yes, a team’s ability to deliver value fast created feedback loops for management: product management, project portfolio management.

(I’m still reading about agile-useful metrics, so I’m sure there is more here.)

If managers worry about flow efficiency, they ask the teams, “What can I do to help your throughput?” The managers manage the project portfolio. Work flows through teams, not through people.

That changes what managers do. Top-level managers (and maybe product managers) define the strategy and talk to customers to see what customers need so they can refine the strategy. Top managers also consider new options for entirely new products—changes in strategy.

Middle managers plan and replan the project portfolio to implement the strategy. First-level managers remove impediments to collaboration.

Let me summarize a little:

Agile managers have a very different role than more traditional managers. They manage differently. Agile managers might use the two pillars of lean: respect for people and continuous improvement as a basis for their management style. To me, that means building relationships with each person the manager “manages,”  the willingness to question all assumptions, and to look at the whole: what does it take for us to succeed as an organization. The idea of one function succeeding instead of all of us vanishes.

Flow efficiency changes the corporate culture: managers change what they discuss. Managers change what they reward. Managers change how they treat people and how they expect people to be treated, because it’s not about the individual “resource.” It’s about the system of work.

The posts so far aside from this post:

I’m quite sure this post is not perfect, but I have other writing to do. I expect to have one more summary post.

Categories: Blogs

You Said Transformation - what do you mean?

Agile Complexification Inverter - Thu, 06/15/2017 - 14:21
Do we mean the words we use - or do we just use them because everyone else does...  you know like the popular buzz word in corporate bingo?  Let's take the word Transformation, as in:

"Hi team, I will be you Agile Coach - let's all do the Agile Transformation thing together.  Out the other end of this transformation we will be a changed company."


Some definitions of Transformation:
  • a thorough or dramatic change in form or appearance.
  • a metamorphosis during the life cycle of an animal.
  • (in physics) the induced or spontaneous change of one element into another by a nuclear process.
In an organizational context, a process of profound and radical change that orients an organization in a new direction and takes it to an entirely different level of effectiveness.
BusinessDictionary.com

Some in the agile world are pulling against this trend... see Dan Mezick's The PUSH of Agile Causes "Trance Formations".
So stop that. And do these things, instead:
  1. Encourage executives and managers to refrain from making decisions for the teams that Scrum very clearly defines as belonging to those teams.
  2. And then, encourage teams to make the decisions that Scrum says are theirs (and theirs alone) to make.
Let's talk about the images this term, transformation creates.  A typical example is the metamorphosis that the caterpillar performs to become the butterfly.  To achieve this transformation the caterpillar spins a chrysalis and then digest itself into protein soup to fuel the development of the butterfly.  Imagine the energy required to perform this feat.  Is your company ready to spend 50% of it stored resources to perform a transformation?


Now let's talk about mental models.  What's the purpose of a mental model - to share it... in this sharing scientific experts have come to understand that the brain waves of the people synchronize into very similar patterns.  One area of research is emotional contagion. “During successful communication, speakers’ and listeners’ brains exhibit joint, temporally coupled, response patterns.” Speaker-listener neural coupling underlies successful communication, is a paper discussing this magic coupling of two people's mental models.


So what do you mean when you say Agile Transformation?  Are our brains in sync?  Do we have similar wave patterns setting up in our minds?  Perhaps not.

Sohota's GuideWhat other words might we use to describe the phenomenon? 
  • Approbation
  • Conversion
  • Evolution
  • Exploration
  • Journey
  • Peregrination
  • Procession
  • Progression
  • Quest
  • Transition
  • Venture
  • Wayfaring



Another from of Transformation occurs for Uber - the Board mandates a transformation.
Uber Board Unanimously Approves All Holder Report Recommendations; Details Secret Until Tuesday


Categories: Blogs

The Simple Leader: Serve

Evolving Excellence - Thu, 06/15/2017 - 10:44

This is an excerpt from The Simple Leader: Personal and Professional Leadership at the Nexus of Lean and Zen


True leadership must be for the benefit of the followers, not the enrichment of the leaders.
– Robert Townsend

Servant leadership has unfortunately become something of a leadership buzzword, yet the concept is sound. Building off of respect, humility, and trust, the servant leader truly thinks of him or herself differently. Instead of being at the top of the pyramid, they are at the bottom. Their job is to serve the organization, their team, or their family by enabling the success of others. By doing so, they enable the success of the organization.

Servant leaders ignite the passion in an organization by drawing the human connection to the task or goal. They unite people rather than place them into silos. They sacrifice when the going gets tough, and this earns them the respect and commitment of the organization.

You may find it hard to think of examples of servant leaders, because most do not desire fame, accolades, or prizes and are therefore not often in the public eye. Two servant leaders who did become famous are Abraham Lincoln and Dr. Martin Luther King, Jr. President Lincoln could have taken the easy route and let the Union dissolve or simply let slavery remain intact. However he took the far more difficult path because he knew it would be better in the long run for the people he was serving. Dr. King eschewed recognition and desired to be remembered for helping drive social justice. He also took the harder approach to creating change by promoting non-violence. Nelson Mandela, Mahatma Gandhi, and Mother Teresa are other examples.

Incredible people, but anyone can be a servant leader. What would happen in your organization, in your team,
or even in your family if you acted like a servant instead of a boss? How would that make you feel? Where and how can you enable success by working to enable the success of others?

Categories: Blogs

Right-Sizing Features for SAFe Program Increments

Agile Product Owner - Wed, 06/14/2017 - 21:01

Hello Folks:

Our friend and ‘mad scientist’ Ian Spence has more than his share of street cred when it comes to working with SAFe. He is the Chief Scientist at Gold Partner Ivar Jacobson International, was one of the first SPCTs in Europe (the highest SAFe certification possible), and has worked with Dean Leffingwell for over 15 years. His deep knowledge of Agile and his vast experience leading large-scale transformations have given him a exceptionally well-rounded understanding of what it takes to succeed with SAFe.

Ian has contributed a new SAFe guidance article, Right-Sizing Features for SAFe Program Increments. He believes that “one of the key activities that will help make your SAFe program a success is the careful preparation of your Features prior to Program Increment (PI) planning. And one important aspect of this preparation is to slice up any of the targeted features that are too large to be easily delivered within a PI.”

The article includes:

  • The differences between features and stories
  • Splitting stories vs. slicing features
  • Good and bad patterns for slicing features

As an added bonus, Ian provides a cool Feature slicing poster that you can download.

I hope you find this new article as interesting and useful as I did.

Always be SAFe,
Richard Knaster and the Framework team
@richardknaster

Categories: Blogs

Right-Sizing Features for SAFe Program Increments

Agile Product Owner - Wed, 06/14/2017 - 17:26

Hello Folks:

Our friend and ‘mad scientist’ Ian Spence has more than his share of street cred when it comes to working with SAFe. He is the Chief Scientist at Gold Partner Ivar Jacobson International, was one of the first SPCTs in Europe (the highest SAFe certification possible), and has worked with Dean Leffingwell for over 15 years. His deep knowledge of Agile and his vast experience leading large-scale transformations have given him a exceptionally well-rounded understanding of what it takes to succeed with SAFe.

Ian has contributed a new SAFe guidance article, Right-Sizing Features for SAFe Program Increments. He believes that “one of the key activities that will help make your SAFe program a success is the careful preparation of your Features prior to Program Increment (PI) planning. And one important aspect of this preparation is to slice up any of the targeted features that are too large to be easily delivered within a PI.”

The article includes:

  • The differences between features and stories
  • Splitting stories vs. slicing features
  • Good and bad patterns for slicing features

As an added bonus, Ian provides a cool Feature slicing poster that you can download.

I hope you find this new article as interesting and useful as I did.

Always be SAFe,
Richard Knaster and the Framework team
@richardknaster

Categories: Blogs

AutoMapper 6.1.0 released

Jimmy Bogard - Wed, 06/14/2017 - 13:25

See the release notes:

v6.1.0

As with all of our dot releases, the 6.0 release broke some APIs, and the dot release added a number of new features. The big features for 6.1.0 include those for reverse-mapping support. First, we detect cycles in mapping classes to automatically preserve references.

Much larger however is unflattening. For reverse mapping, we can now unflatten into a richer model:

public class Order {  
  public decimal Total { get; set; }
  public Customer Customer { get; set; } 
}
public class Customer {  
  public string Name { get; set; }
}

We can flatten this into a DTO:

public class OrderDto {  
  public decimal Total { get; set; }
  public string CustomerName { get; set; }
}

We can map both directions, including unflattening:

Mapper.Initialize(cfg => {  
  cfg.CreateMap<Order, OrderDto>()
     .ReverseMap();
});

By calling ReverseMap, AutoMapper creates a reverse mapping configuration that includes unflattening:

var customer = new Customer {  
  Name = "Bob"
};
var order = new Order {  
  Customer = customer,
  Total = 15.8m
};

var orderDto = Mapper.Map<Order, OrderDto>(order);

orderDto.CustomerName = "Joe";

Mapper.Map(orderDto, order);

order.Customer.Name.ShouldEqual("Joe");  

Dogs and cats living together! We now have unflattening.

Enjoy!

Categories: Blogs