Skip to content


Currying: A Functional Alternative To fn.bind

Derick Bailey - new ThoughtStream - Fri, 06/24/2016 - 13:30

In my quest to learn functional programming with JavaScript, I seem to have been focusing on the idea of currying – taking a function that expects more than one argument, and turning it into a series of functions that only take one argument, executing the original function once all required arguments have been supplied.

In the last few weeks – with the help of everyone in the WatchMeCode community slack – I’ve found a places where currying seems to be beneficial. One of those places is a replacement for a function’s .bind method.

Curry vs bind

What Does .bind Do?

The .bind method – available on every function in JavaScript – allows you to do 2 things: specify the context (“this”) for the function, and specify one or more arguments that the function will receive when it is finally executed.

In this example, I have a basic add function on which I call the .bind method. The first parameter – undefined, in this case – sets the value of “this”. The second parameter – 1 – sets the first argument that will be passed to the function when it is finally executed.

The result of the .bind call is a new function. When I call this function, it only needs 1 parameter to execute.

The general term for what just happens is “partial functional application”. That is, the function was partially applied with the .bind call to set the context and the first parameter.

The final execution of the function didn’t happen until later, when I invoked the function, passing in one more argument in this case.

This is a common pattern – I’ve used partial function application in a lot of code, over the years. But now, with currying in my tool belt, I see less need for this.

Currying The Add Function

With currying, we can get the same effect as the partial function application from above, but without using the .bind method. The intermediate steps, though, provide much more flexibility than .bind does.

Let’s take the same add function, and manually curry it, as I showed in my video on the basics of currying.

In this example, there are 2 functions. The first function, add, takes a single parameter and returns the second function. The second function also takes a single parameter and then executes the addition, returning the result.

Both the .bind code above, and this code, show an “add1” method that is the result of the first operation. The both show the resulting function taking a single, second parameter to perform the calculation, as well.

I have effective produced the result of partial function application, using currying instead of .bind.

So, what’s the real difference? Is currying better than .bind? Why?

A Functional Alternative

For the simple comparison above, there is very little in benefit to using currying vs .bind.

But there are 2 major improvements that currying offers over .bind.

  1. I don’t have to specify the context (“undefined”, in that example) when currying
  2. Currying can reduce the code by not chaining function calls

While you can .bind any function – including an already partially applied function – you end up with some rather ugly code with the .bind littered everywhere.

This example shows how you’re required to continuously pass the context parameter to the .bind call, even though it’s never being used.

The currying alternative gives you slightly less code, as well:

Here, the code is a little more succinct. The use of ramda’s curry method allows you to curry the same function that was previously used.

If you’re wondering about supplying multiple parameters, though, both the .bind and curried version can do that:

There’s very little difference in this code, when it comes down to it. Do you want to supply the “undefined” parameter, or add extra parenthesis?

All this of this leads to the question…

Is Currying Better?

I don’t know if currying is “better” or “worse” or even “more flexible” than partial function application – at least not in these examples.

I think they can largely be interchanged, based on what you’re more comfortable using.

However, currying gives you options for additional functional programming tools and techniques.

From what little I know of functional code, it is common for composition, mapping and other tools to require functions only take a single argument. And in these examples, currying would likely be the choice to make it happen – though I bet you could make it work with .bind, as well.

For now, at least, I can say that currying does provide a functional alternative to the .bind method. And, frankly, I find it easier read the curried version of my code, when compared to .bind calls everywhere.

Categories: Blogs

Links for 2016-06-23 []

Zachariah Young - Fri, 06/24/2016 - 09:00
Categories: Blogs

Article Review: Thinking About the Agile Manifesto

Learn more about transforming people, process and culture with the Real Agility Program

Often times, as I’ve been researching about agile methods and how to apply these to create real and sustainable change in an organization, I come across reference to the Agile Manifesto. I list it here today for those who are new to the field or who are getting back to the roots after trying a few things with different-than-expected results. It is an instrumental document. The values and principles listed here truly do shape the way agilists think and operate and to some degree or another the results appear to be better than before this founding document was introduced. So here is my “hats off” to this remarkable item which plays a pivotal role in cultural transformation.

The four key values are:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Personally, I find the first one the most meaningful of all. When we value individuals and interactions over process and tools we are truly improving in leaps and bounds in creating collaborative environments which are continuously improving.

Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!

The post Article Review: Thinking About the Agile Manifesto appeared first on Agile Advice.

Categories: Blogs

Just released! SAFe 4.0 Leading SAFe LiveLessons video training

Agile Product Owner - Thu, 06/23/2016 - 17:42

leading_safe_4_live_lessons_300With so many enterprises adopting SAFe over the years, we’ve learned what works, what doesn’t, and what the success stories have in common. One thing we know for certain—implementations that deliver results may vary somewhat in context and execution, but all share a common attribute; a workforce well trained and educated in SAFe practices, and a desire for continuous learning and improvement.

Experience tells us that face-to-face training is ideal, but realities in the field can sometimes make it difficult for folks to attend a public class. We get that, and that’s why we’ve provided this video tutorial: Leading SAFe® 4.0 Live Lessons: Leading the Lean-Agile Enterprise with the Scaled Agile Framework®.

It bridges the gap for people who may not be able to initially attend the 2-day Leading SAFe certification course, but still need to gain the knowledge necessary to start or continue their Lean-Agile transformation by leveraging SAFe. The self-paced LiveLessons video format is ideal for busy professionals as it allows you to explore one topic at one time and then come back later and learn a different subject.

What you’ll learn

The course is delivered in nine lessons where I present high-level overviews, as well as specifics where needed, exercises to test the viewer on what they’ve learned, and at the end of the course, clear-cut steps to start the journey of transformation. After watching this video, viewers can expect to have an understanding of the Scaled Agile Framework; Lean thinking and embracing Agility: how to apply SAFe principles; how to plan, execute, and implement an Agile Release Train; how to build an Agile Portfolio; how to build really large systems with the Value Stream layer, and how to scale leadership to the next level of enterprise performance.

Fully updated to SAFe 4.0

If you’re familiar with the SAFe 3.0 version of this video, I can tell you (from sitting in front of a video camera for three days) that this is an entirely new video produced specifically for SAFe 4.0, and covers the latest benefits that can be achieved through the new Framework for software and systems-dependent enterprises.

More information and discount promotions can be found at There is also an option for enterprise licensing if you’re dealing with a larger scale training initiative.

We’re committed to providing these resources to the SAFe community, and welcome your feedback on the video, and your experience with this type of training.

Stay SAFe!

Categories: Blogs

An Essential Update on Essential SAFe

Agile Product Owner - Thu, 06/23/2016 - 17:34

Earlier this year, we published our first draft of the Essential SAFe® Big Picture via blog post. Since then, we have received lots of comments, from the blog, our classroom settings, direct customer and analyst feedback, and more. It’s compellingly obvious that this simpler, essential view is a clear aid to understanding the minimum roles and practices that are necessary to be successful with a SAFe implementation.

Simple is good. Feedback is good, too. To that end, we have now incorporated the input and present an updated version of the Essential SAFe® Big Picture:

 the core of the framework, critical to every implementation. Figure 1. Essential SAFe: the core of the framework, critical to every implementation.

Here are the nine key elements of Essential SAFe; without which, an implementation of the framework really isn’t “safe”:

  • SAFe Lean-Agile Principles. Lean-Agile principles provide the basis for every successful transformation and guide decision making as the process evolves and adapts.
  • Lean-Agile Leaders. Successful transformations are based on educating management to become “lean-thinking manager-teachers”. Thereafter, they lead, rather than follow, the transformation.
  • Agile Teams, Agile Release Trains, Value Streams. The Agile Release Train is a key building block of a SAFe enterprise. Trains are organized around Value Streams, and consist of Agile Teams. Teams use Scrum, Kanban and Built-in Quality practices to frequently produce integrated increments of value. DevOps practices close the loop on customer value delivery.
  • Cadence. A standardized PI and iteration cadence is the heartbeat of every ART and Value Stream. Periodic synchronization of all aspects limits variance to a single time interval.
  • Key Program Events. PI Planning, System Demo, and Inspect and Adapt assure that teams plan together, implement and demo together, and routinely improve their processes.
  • IP Iteration. The Innovation and Planning iteration is like extra oxygen in the tank: without it the train may start gasping under the pressure of the tyranny of the urgent, a plan that forgives no mistakes, nor provides dedicated time for innovation.
  • Critical Roles. Product Management, RTE, and System Arch/Eng— provide content and technical authority, and an effective development process. Product Owners and Scrum Masters help the teams meet their objectives. The Customer is part of the Value Stream, and is integrally engaged throughout development.
  • Vision and Backlog. Vision, backlogs and economic prioritization deliver business results by assuring that the teams are building the right thing.
  • Architectural Runway. Architectural runway provides “just enough” technical enablement to keep program velocities high, and avoid excessive redesign.

Of course, we are still open for feedback, so feel free to comment away. In addition, I think this is where we are headed next:

  1. Create a guidance article for Essential SAFe, so it can become a permanent part of the knowledge base
  2. Over time we will make the picture in the article clickable, allowing the viewer to navigate to a specific article from there
  3. Provide an Essential SAFe® poster PDF for download
  4. Incorporate this simpler thinking into some future version of SAFe (yes, @Chris, we really did say that …)

Also, Inbar is presenting Essential SAFe® at Agile Israel this week. We will share his presentation materials at some point soon. I’ll also be scheduling a webinar on the topic, probably in August. There I will discuss—not only what is essential in SAFe®—but also how other SAFe® constructs can be adapted to best fit your enterprise context. The link will be available soon, so stay tuned for that.

Please share your thoughts in the comments below. Without your input, there’s no “C” (and therefore, no “A”) in our PDCA cycle. Thank you and be safe, essentially speaking…

-Alex, and the Framework team: Dean, Inbar, Richard

Categories: Blogs

Product Owners and Learning, Part 3

Johanna Rothman - Thu, 06/23/2016 - 16:32

Part 1 was about how the PO needs to see the big picture and develop the ranked backlog. Part 2 was about the learning that arises from small stories. This part is about ranking.

If you specify deliverables in your big picture and small picture roadmaps, you have already done a gross form of ranking. You have already made the big decisions: which feature/parts of features do you want when? You made those decisions based on value to someone.

I see many POs try to use estimation as their only input into ranking stories. How long will something take to complete? If you have a team who can estimate well, that might be helpful. It’s also helpful to see some quick wins if you can. See my most recent series of posts on Estimation for more discussion on ranking by estimation.

Estimation talks about cost. What about value? In agile, we want to work (and deliver) the most valuable work first.

Once you start to think about value, you might even think about value to all your different somebodies. (Jerry Weinberg said, “Quality is value to someone.”)  Now, you can start considering defects, technical debt, and features.

The PO must rank all three possibilities for a team: features, defects, and technical debt. If you are a PO who has feature-itis, you don’t serve the team, the customer, or the product. Difficult as it is, you have to think about all three to be an effective PO.

The features move the product forward on its roadmap. The defects prevent customers from being happy and prevent movement forward on the roadmap. Technical debt prevents easy releasing and might affect the ease of the team to deliver. Your customers might not see technical debt. They will feel the effects of technical debt in the form of longer release times.

Long ago, I suggested that a specific client consider three backlogs to store the work and then use pair-wise comparison with each item at the top of each queue. (They stored their product backlog, defects, and technical debt in an electronic tool. It was difficult to see all of the possible work.) That way, they could see the work they needed to do (and not forget), and they could look at the value of doing each chunk of work. I’m not suggesting keeping three backlogs is a good idea in all cases. They needed to see—to make visible—all the possible work. Then, they could assess the value of each chunk of work.

You have many ways to see value. You might look at what causes delays in your organization:

  • Technical debt in the form of test automation debt. (Insufficient test automation makes frictionless releasing impossible. Insufficient unit test automation makes experiments and spikes impossible or quite long.)
  • Experts who are here, there, and everywhere, providing expertise to all teams. You often have to wait for those experts to arrive to your team.
  • Who is waiting for this? Do you have a Very Important Customer waiting for a fix or a feature?

You might see value in features for immediate revenue. I have worked in organizations where, if we released some specific feature, we could gain revenue right away. You might look at waste (one way to consider defects and technical debt).

Especially in programs, I see the need for the PO to say, “I need these three stories from this feature set and two stories from that other feature set.” The more the PO can decompose feature sets into small stories, the more flexibility they have for ranking each story on its own.

Here are questions to ask:

  • What is most valuable for our customers, for us to do now?
  • What is most valuable for our team, for us to do now?
  • What is most valuable for the organization, for us to do now?
  • What is most valuable for my learning, as a PO, to decide what to do next?

You might need to rearrange those questions for your context. The more your PO works by value, the more progress the team will make.

The next post will be about when the PO realizes he/she needs to change stories.

If you want to learn how to deliver what your customers want using agile and lean, join me in the next Product Owner workshop.

Categories: Blogs

Product Owners and Learning, Part 4

Johanna Rothman - Thu, 06/23/2016 - 15:05

Part 1 was about how the PO needs to see the big picture and develop the ranked backlog. Part 2 was about the learning that arises from small stories. Part 3 was about ranking. In this part, I’ll discuss the product owner value team and how to make time to do “everything,” and especially how to change stories.

Let’s imagine you started developing your product before you started using agile. Your product owners (who might have been a combination of  product managers and business analysts) gave you a list of features, problems, and who knows what else for a release. They almost never discussed your technical debt with you. In my experience, they rarely discussed defects unless a Very Important Customer needed something fixed. Now, they’re supposed to provide you a ranked backlog of everything. It’s quite a challenge.

Let’s discuss the difference between a product manager and a product owner.


A product manager faces outward, seeing customers, asking them what they want, discussing dates and possibly even revenue. The product manager’s job is to shepherd the customer wishes into the product to increase the value of the product. In my world, the product manager has the responsibility for the product roadmap.

A product owner faces inward, working with the team. The PO’s job is to increase the value of the product. In my world, the PO works with the product manager (and the BAs if you have them) to create and update the product roadmap.

A business analyst might interview people (internal and external) to see what they want in the product. The BA might write stories with the PO or even the product manager.

The product manager and the product owners and any BAs are part of the Product Owner value team. The product owner value team works together to create and update the product roadmap. In a large organization, I’ve seen one product manager, several product owners and some number of BAs who work on one product throughout its lifetime. (I’ve also seen the BAs move around from product to product to help wherever they can be of use.)

What about you folks who work in IT and don’t release outside the company? You also need a product manager, except, with any luck, the product manager can walk down the hall to discuss what the customers need.

If you work in a small organization, yes, you may well have one person who does all of this work. Note: a product manager who is also a product owner is an overloaded operator. Overloaded people have trouble doing “all” the work. Why? Because product management is more strategic. Product ownership is more tactical.  You can’t work at different levels on an ongoing basis. Something wins—either the tactical work or the strategic work. (See Hiring Geeks That Fit for a larger discussion of this problem.)

When one person tries to do all the work, it’s possible that many other things suffer: feedback to the team, story breakdown, and ranking.

The Product Owner Value team takes the outside-learned information from customers/sponsors, the inside-learned information from the product development team (the people who write and test the product), and develop the roadmap to define the product direction.

In agile, you have many choices for release: continuous delivery, delivery at certain points (such as at the end of the iteration or every month or whenever “enough” features are done), or monthly/quarterly/some other time period.

Here’s the key for POs and change: the smaller the stories are or the more often the team can release stories, the more learning everyone gains. That learning informs the PO’s options for change.

Example.AgileRoadmapOneQuarterIn this example roadmap, you can see parts of feature sets in in the first and second iterations. (I’m using iterations because they are easy to show in a picture and because people often want a cadence for releasing unless you do continuous delivery.)

If the Product Development team completes parts of feature sets, such as Admin, Part 1, the PO can decide if Admin, Part 2 or Diagnostics, Part 1 is next up for the team. In fact, if the PO has created quite small stories, it’s really easy to say, “Please do this story from Admin and that story from Diagnostics.” The question for the PO is what is most valuable right now: breadth or depth?

The PO can make that decision, if the PO has external information from the Product Manager and internal information from the BA and the team. The PO might not know about breadth or depth or some combination unless there is a Product Owner Value team.

Here are some questions when your PO wants everything:

  • What is more valuable to our customers: breadth across which parts of the product, or depth?
  • What is more valuable for our learning: breadth or depth?
  • Does anyone need to learn something from any breadth or depth?
  • What cadence of delivery do we need for us, our customers, anyone else?
  • What is the first small step that helps us learn and make progress?

These questions help the conversation. The roadmaps help everyone see where the Product Owner Value team wants the product to go. I’ll do a summary post next. (If you have questions I haven’t answered, let me know.)

Someone needs to learn about what the customers want. That person is outward-facing and I call that person a Product Manager. Someone needs to create small stories and learn from what the team delivers. I call that person a Product Owner. Those people, along with BAs compose the Product Owner Value team, and guide the business value of the product over time. The business value is not just features—it is also when to fix defects for a better customer experience and when to address technical debt so the product development team has a better experience delivering value.

I’ll do a summary post next. (If you have questions I haven’t answered, let me know.)

If you want to learn how to deliver what your customers want using agile and lean, join me in the next Product Owner workshop.

Categories: Blogs

Who Owns This House?

Leading Agile - Mike Cottmeyer - Thu, 06/23/2016 - 13:30

That was the question that was posed to the freshly minted staff at the Open House for Friends and Family for Publix Grocery Stores store #1520 yesterday. It was amazing to be invited to witness the internal opening of one of Publix’s newest stores in Cary, NC.

The air was thick with excitement. Executives traveled in from the regional offices in Charlotte and from the corporate headquarters in Tampa, FL. We met the store leadership. We met everyone.

Employees pose for Publix Store #1520's Grand Opening

Employees pose for Publix Store #1520’s Grand Opening

When it came time for the ribbon cutting, the newly minted store manager took the stage and posed this question, “Who owns this house?” It was met with a resounding, “We own this house!”

Three times the call came.

Three times it was met with with a loud cheer, “We own this house!”

Kevin Murphy, SVP of Retail Operations, summed up Publix’s success as being rooted in two key principles: ownership and pride in your work at every level of the organization. Kevin should know. He started as a front-service clerk at a Publix in 1984. He worked in various positions before being promoted to store manager in 1995. He was promoted to Jacksonville Division district manager in 2003, Atlanta Division regional director in 2009, Miami Division VP in 2014, and his current position was created in 2016.

Ownership and pride in work at all levels. Sounds like the same formula for success in Agile Product Development.

This is also the core of LeadingAgile’s approach to transformation from Basecamp One through Basecamp Five. Without local ownership of decision making at the point of the work being done, we send the message consciously on subconsciously that we don’t trust that the work being performed is high-quality and valuable.

If it isn’t valuable then why are you doing it? Non-valuable work is called waste.

If the work isn’t high-quality, then why? Do you have the correct expectations of how long the work should take? Are you measuring quality correctly? (hint: it’s not just about defect injection rate.) Do you reward the wrong things like heroic efforts?

This is the heart of Agile practices. It expects ownership and pride in work. It expects trusting the people doing the work to know what they are doing. If they don’t, it expects you to let them self-organize to the extent that people who know how to do the work well, can volunteer to do it with the expectation that they also mentor those that don’t.

What about your company? Does it espouse a culture of ownership and pride in work? How would you know? Our assessments cut right to the heart of the matter and help organizations determine if leadership is creating and empowering a culture of ownership and pride in work.

Wouldn’t you like to know?

Congratulations to the people of Publix Store #1520. I can’t wait to experience more ownership and pride in work. The world needs more of it.

hbspt.forms.create({ portalId: '1715664', formId: '6f71845c-7384-4313-b089-1c3b4b7bf134' });

The post Who Owns This House? appeared first on LeadingAgile.

Categories: Blogs

Product Owners and Learning, Part 1

Johanna Rothman - Wed, 06/22/2016 - 18:05

When I work with clients, they often have a “problem” with product ownership. The product owners want tons of features, don’t want to address technical debt, and can’t quite believe how long features will take.  Oh, and the POs want to change things as soon as they see them.

I don’t see this as problems.To me, this is all about learning. The team learns about a feature as they develop it. The PO learns about the feature once the PO sees it. The team and the PO can learn about the implications of this feature as they proceed. To me, this is a significant value of what agile brings to the organization. (I’ll talk about technical debt a little later.)

AgileRoadmap.copyright-1080x794One of the problems I see is that the PO sees the big picture. Often, the Very Big Picture. The roadmap here is a 6-quarter roadmap. I see roadmaps this big more often in programs, but if you have frequent customer releases, you might have it for a project, also.

I like knowing where the product is headed. I like knowing when we think we might want releases. (Unless you can do continuous delivery. Most of my clients are not there. They might not ever get there, either. Different post.)

Here’s the problem with the big picture. No team can deliver according to the big picture. It’s too big. Teams need the roadmap (which I liken to a wish list) and they need a ranked backlog of small stories they can work on now.

Example.AgileRoadmapOneQuarter In Agile and Lean Program Management, I have this picture of what an example roadmap might look like.

This particular roadmap works in iteration-based agile. It works in flow-based agile, too. I don’t care what a team uses to deliver value. I care that a team delivers value often. This image uses the idea that a team will release internally at least once a month. I like more often if you can manage it.

Releasing often (internally or externally) is a function of small stories and the ability to move finished work through your release system. For now, let’s imagine you have a frictionless release system. (Let me know if you want a blog post about how to create a frictionless release system. I keep thinking people know what they need to do, but maybe it’s as clear as mud to  you.)

The smaller the story, the easier it is for the team to deliver. Smaller stories also make it easier for the PO to adapt. Small stories allow discovery along with delivery (yes, that’s a link to Ellen Gottesdiener’s book). And, many POs have trouble writing small stories.

That’s because the PO is thinking in terms of feature sets, not features. I gave an example for secure login in How to Use Continuous Planning. It’s not wrong to think in feature sets. Feature sets help us create the big picture roadmap. And, the feature set is insufficient for the frequent planning and delivery we want in agile.

I see these problems in creating feature sets:

  • Recognizing the different stories in the feature set (making the stories small enough)
  • Ranking the stories to know which one to do first, second, third, etc.
  • What to do when the PO realizes the story or ranking needs to change.

I’ll address these issues in the next posts.

If you want to learn how to deliver what your customers want using agile and lean, join me in the next Product Owner workshop.

Categories: Blogs

Product Owners and Learning, Part 2

Johanna Rothman - Wed, 06/22/2016 - 18:03

In Part 1, I talked about the way POs think about the big picture and the ranked backlog. The way to get from the big picture to the ranked backlog is via deliverables in the form of small (user) stories. See the wikipedia page about user stories. Notice that they are a promise for a conversation.

I talked about feature sets in the first post, so let me explain that here. A feature set is several related stories. (You might think of a feature set as a theme or an epic.) Since I like stories the team can complete in one day or less, I like those stories to be small, say one day or less. I have found that the smaller the story, the more feedback the team gets earlier from the product owner. The more often the PO sees the feature set evolving, the better the PO can refine the future stories. The more often the feedback, the easier it is for everyone to change:

  • The team can change how they implement, or what the feature looks like.
  • The PO can change the rest of the backlog or the rank order of the features.

I realize that if you commit to an entire feature set or a good chunk for an iteration, you might not want to change what you do in this iteration. If you have an evolving feature set, where the PO needs to see some part before the rest, I recommend you use flow-based agile (kanban). A kanban with WIP limits will allow you to change more often. (Let me know if that part was unclear.)

Now, not everyone shares my love of one-day stories. I have a client whose team regularly takes stories of size 20 or something like that. The key is that the entire team swarms on the story and they finish the story in two days, maybe three. When I asked him for more information, he explained this it in this way.

“Yes, we have feature sets. And, our PO just can’t see partial finishing. Well, he can see it, but he can’t use it. Since he can’t use it, he doesn’t want to see anything until it’s all done.”

I asked him if he ever had problems where they had to redo the entire feature. He smiled and said,

“Yes. Just last week we had this problem. Since I’m the coach, I explained to the PO that the team had effectively lost those three days when they did the “entire” feature instead of just a couple of stories. The PO looked at me and said, “Well, I didn’t lose that time. I got to learn along with the team. My learning was about flow and what I really wanted. It wasn’t a waste of time for me.”

“I learned then about the different rates of learning. The team and the PO might learn differently. Wow, that was a big thing for me. I decided to ask the PO if he wanted me to help him learn faster. He said yes, and we’ve been doing that. I’m not sure I’ll ever get him to define more feature sets or smaller stories, but that’s not my goal. My goal is to help him learn faster.”

Remember that PO is learning along with the developers and testers. This is why having conversations about stories works. As the PO explains the story, the team learns. In my experience, the PO also learns. It’s also why paper prototypes work well. Instead of someone (PO or BA or anyone) developing the flow, when the team develops the flow in paper with the PO/BA, everyone learns together.

Small stories and conversations help the entire team learn together.

Small features are about learning faster. If you, too, have the problem where the team is learning at a different rate than the PO, ask yourself these questions:

  • What kind of acceptance criteria do we have for our stories?
  • Do those acceptance criteria make sense for the big feature (feature set) in addition to the story?
  • If we have a large story, what can we do to show progress and get feedback earlier?
  • How are we specifying stories? Are we using specific users and having conversations about the story?

I’ve written about how to make small stories in these posts:

The smaller the story, the more likely everyone will learn from the team finishing it.

I’ll address ranking in the next post.

If you want to learn how to deliver what your customers want using agile and lean, join me in the next Product Owner workshop.

Categories: Blogs

Team Metrics - Case Study

Agile Complexification Inverter - Wed, 06/22/2016 - 17:57
Let's look at an info-graphic of a beginning team's metrics and use this as a case study in Scrum Team Metrics.

Description of charts:

Burndown chart - a daily count of the number of task units (aspirin is this teams selected units for task estimation) not done.  This includes the task yet to be started, and task in process.

Tasks in Process - a daily count of the number of tasks in process.

Tasks Done - a daily count of the number of tasks that are done.

Stories Done - a daily count of the number of Stories that are done.

Velocity - the empirical measure of Stories that are considered done by the team and accepted as done by the Product Owner during the Sprint Review.

The Back Story on this team:

This team had been attempting to do some form of ad-hoc Scrum / Kanban with little guidance and understanding of the process.  The Kanban aspect came from the company's tooling (RTC) template - not from any real practices the team was implementing.   After some weeks of observations and workshops with the team - they decided to "hit the reset button" on doing Scrum.  Sprint One in the info-graphic is the first sprint right after a week long workshop on learning Scrum practices and principles.  Key to this team's adoption of Scrum is their adoption of a physical task board (see also Elements of an Effective Scrum Task Board).

Observations on Sprints:

Sprint One - Started with many stories from past sprint that were not yet done - as the team had no empirical data of velocity we guessed at how many stories we could complete in the 2 week sprint, and chose 15 stories.  At this point we had 4 product silos where people we working within the silo to deliver the stories - very little cross team collaboration.

Rules siloSprint Two - Tear down the silo walls - the team decided that the original silos of working was harming a long term desire of cross-functional team members - so a removal of the silo walls (tape on the scrum task board) happened.

Sprint Three - Enforced the use of empirical data to constrain the team's selection of how many stories to bring into the sprint (team select top 5 stores and finished all of them).

Sprint Four - Team planed for 30 points of stories but finished early and pulled in additional stories and finished them within the sprint.

Objectives for the Team:

This teams objectives for hitting the reboot button on a scrum implementation was to achieve a consistent level of reliability to deliver value (stories) to the business.  Also to maintain and supporting the existing 4 products line internal organizational clients, and transitioning tacit knowledge from several remote employees to the team and increasing cross-functional capabilities of the team members.

Commentary on Metric Charts:

Burndown - Sprint 1 and 2 task burndown charts show that the team started with around 100 aspirin and discovered between 50 and 100 aspirin more by doing the work - but didn't finish the 15 stories and left lots of stories started but incomplete at the end of the sprint.  In sprint 3 and 4 the team had developed the ability to forecast the proper amount of work to pull into sprint planning and were able to deliver the completed stories.

Tasks in Process - this simple metric showed that the team of about 8 people were consistently task switching.  There are many "reasons" (excuses) for this behavior, and it is a hard habit to correct in this era of high utilization rate driven management.  Just tracking this metric had little effect on the teams behavior - however we had empirical data that other practices (avatars, re-estimating in process tasks, etc.) had a positive effect upon this metric over several sprints.

Tasks Done - this metric is redundant for a team using a traditional sticky note task board.  In general this reflects the sprint burndown.  It does point out for this team that tasks done stalls out when there support tasks flare up, as these support (maintenance and production, M&P) issues require task switching to the more urgent unplanned work.  Reflecting upon this metric lead the team to start tracking the planned tasks separate from the urgent support tasks in our burndown chart for sprint 5.

Stories Done - an interesting trend shows up in this simple to trend metric.  The team was capable of finishing 5 stories, regardless of how many they planned.  In sprint 3 when the team constrained the planning to the empirical evidence (~28 points, 5 stories) they had there first successful sprint (on time, on budget, with planned scope).

Capabilities developed by the Team not shown in these Metrics:

Tasking - working toward tiny tasks.  Within the first two sprints the focus was to develop the ability to task stories.  Several synergic practices lead to this capability - re-estimating each time the task is touched in stand-up; recognizing that task that last for several days are way-too-large;  learning to decompose tasks that are too large; realizing that doing work leads to discovery of new tasks that need to be recorded and added to the board.  See Also: What belongs on the TASKS board?

Single Piece Flow - working on a task until it is done.  Smaller task effect this behavior in a virtuous manner.  Re-estimating each day makes the antithesis of this pattern apparent, and also offers the opportunity for team members to recognize when help is needed.  The use of avatars on the story tasks reinforces the practice of lowering work in process and reducing task switching.

In Sprint 5 the team decided to move from a 2 week time box to a 3 week sprint. The charts also show the support (M&P) tasks tracking independently of the planned tasks and the new chart at the bottom (M&P task vs Planned task deltas per day) indicates the inverse relationship of the priority shifts the team has to deal with.

Next Objectives:

Develop the capabilities to deliver agile release plans and forecast feature release time frames for business coordination with other teams that depend upon the infrastructure product lines developed by this team.

At the team coaching level an objective is to measure cycle time of stories within scrum teams.

See Also:
Metrics for a Scrum Team - 10 suggested metrics and examples
Measuring Process Improvements - Cycle Time by Mishkin Berteig, June 2008
7 Lean metrics to Improve Flow - LeanKit
Categories: Blogs

How to Have Better Fridays

J.D. Meier's Blog - Wed, 06/22/2016 - 17:50

Recently, I’ve been teaching more people Agile Results. 

I teach them really fast, because I just focus on teaching them the most important tool in Agile Results:

Monday Vision, Daily Wins, Friday Reflection

But before I walk through, I share a quick story of how it all started.

Monday Vision was Born for Better Fridays

It was a warm, sunny, Friday afternoon.
My colleague and I were on our way to our favorite pizza place.
It was a beautiful day.  It should have been a great day.
But I felt like a beast of burden with the weight of the world on my back.
Our backlog was overflowing, we didn’t make it through what we thought we would, and we had been slogging away.
And for what?
Well, I caught myself looking in the rear view mirror, more than looking ahead.
Instead of feeling great, I felt like crap.
So I turned to my colleague and asked him how much we realistically have to spend on work when we get back.
We lied to each other and ourselves.  Then we got real.
We figured the best thing we could possibly do would be to prioritize the value we could deliver next week.
With that, we enjoyed our pizza, and when we got back to work, we figured out what a great next week would look like.
I never wanted us to have another Friday where we couldn’t go into weekend feeling good about what we had accomplished for the week.
And that’s how Monday Vision was born.

Monday Vision, Daily Wins, Friday Reflection for Better Fridays

One I tell that little story, people get it pretty quickly.  They’ve been there.  They feel the pain.

They slogged away all week and at the end of the week, instead of feeling good about their achievements, they feel like they haven’t done enough.

They are never done.  They are overwhelmed. 

Instead of feeling like they earned their weekend for rest and relaxation, they feel guilty that they should work on their never-ending backlog and laundry-list of To-Dos.

Monday Vision for Better Fridays

So then I walk them through how to do Monday Vision, so they can have better Fridays.

On Mondays, imagine if it were Friday.  Really step into your future Friday and feel it.   What are Three Wins you really want to have under your belt?

What would you want to be able to say to your manager or to your team or to yourself, about what you accomplished or achieved for the week?

Get clarity on that.

Use that simple story of your Three Wins that you want to be able to talk about on Friday, as your way to prioritize your focus for the week on Monday.

Now you are doing “Monday Vision.”

Daily Wins for Better Fridays

Each day, identify your Three Wins for that day.  This is the “Daily Wins” practice.

You will have those days where your Three Wins might be, “Great Breakfast,” “Great Lunch”, “Great Dinner.”

There will be days that knock you down, and you wonder how you will get back up.

But then you will also have those days where you are on top of the world and your Three Wins for today will be magnificent.

You might even say, they will be your masterpiece.

Either way, get in the habit of starting your day by identifying Three Wins you want to achieve.

That will help you focus and prioritize all that you do in a more meaningful way for results that matter.

If you don’t know how to do this, just imagine if you were closing out your day, what are Three Wins that you want to be able to say you’ve achieved, either to you, your manager, your team or that someone special.

Friday Reflection for Better Fridays

Lastly, there is Friday Reflection.

Friday Reflection is your chance to dig deep and gain some new personal productivity insights.

Ask yourself, “What are three things going well?” and ask yourself, “What are three things to improve?”

Be honest with yourself about your answers.

You are the one that will win or lose from what you learn.

This is your chance to change any long-standing patterns of your personal productivity challenges.

Do you bite off more than you can chew?  Do you get randomized during the week?

Do you have a hard time figuring out what is actually valued?

Use what you learn to feed into next week.  This is your chance to change and practice your Growth Mindset.

Don’t expect any of these exercises to be easy, but they get easier with practice.

And that’s just it.  This isn’t a one-time trick.

This is a very precise set of productivity habits and practices that you can use for your lifetime to master time management, master your energy, master your motivation, and become more of what you are capable of.

Unleash your productivity, the Agile Way.

Best wishes for better Fridays.

Categories: Blogs

Agile worden door agile te doen

Ben Linders - Wed, 06/22/2016 - 13:30

Agile worden door agile te doen - Ben LindersAgile is hot! Kleine en grotere organisaties zijn bezig met het invoeren van agile, vaak met (grootschalige) veranderprogramma’s die niet altijd tot succes leiden. Met een plan wordt je niet agile, dat gebeurd door daadwerkelijk te veranderen, door het te doen. De vraag is: Hoe kun je agile worden door agile te doen.

Agile is geen doel, het is een middel wat je slim toepast om sneller en flexibeler te worden en meer waarde te leveren. Agile principes en practices van b.v. Scrum en Kanban helpen om je de agility van je organisatie te verhogen. Agile doen


Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

Als ik organisaties help bij het toepassen van agile dan begin ik vaak met kleine veranderingen waar op kortere termijn winst te halen is. Van zulke veranderingen leert de organisatie dat ze kunnen veranderen. Ze zien de waarde van de verandering snel terug. Dat versterkt het effect en geeft energie voor verdere verandering. Ze worden meer agile door agile te doen.

Ook pak ik die veranderingen aan waar een groot risico zit. “Learn fast by failing fast.” Dat helpt ook om mensen wakker te schudden. Als het lukt, dan is het een mooi bewijs dat veranderen kan. Gaat het fout, dan weten we dat die aanpak niet de oplossing is. Een leermoment waarvan we beter en sterker worden. Kortom, het kan niet fout gaan. Agile zijn

Managers vragen mij wanneer ze “agile zijn”. Agile is nooit “af”. Het is geen kwestie van Scrum, Kanban of SAFe invoeren. Het is een reis van continue verbetering, waarin de resultaten van de organisatie steeds verder groeien. Onderweg borg je veranderingen om te zorgen voor blijvend resultaat.

Met agile worden organisaties beter in staat om zich aan te passen aan veranderingen in hun omgeving, en leveren ze meer waarde aan bestaande en nieuwe klanten. Dat houdt nooit op, gelukkig maar. Agile worden

Het nadeel van een veranderprogramma met een plan is dat het de suggestie wekt dat er een einddoel is waarin de organisatie agile is. Om geen verkeerde verwachtingen te wekken werkt ik bij voorkeur met een verander backlog. Daarin staat wat we de komende tijd gaan doen, en waarom we dat doen, om agile te worden. Continue verbeteren met Agile!

Met de feedback van de veranderingen, veranderen de prioriteiten in de veranderbacklog. Er komen dingen bij en vallen er dingen af. We komen nooit op een punt waarop alles gedaan is. We zorgen er op deze manier wel voor dat we met de belangrijkste veranderingen bezig zijn. Is dat genoeg? Voor veel organisaties wel! Continu Verbeteren

continu verbeterenVerbeteren kan en moet anders. Continu maar beheerst veranderen, in kleine stapjes op weg naar meer resultaten. Mijn aanpak maakt de veranderingen inzichtelijk en geeft stakeholders een instrument om mee te sturen. De workshop continu verbeteren met Agile zorgt voor tevreden klanten, stakeholders en medewerkers!

Hopelijk heeft dit artikel je geholpen om manieren te vinden om agile worden door agile te doen. Ik ben benieuwd naar jouw ervaringen. Wat doe je om de agility te verhogen? Wat werkt, en wat niet? Deel je ervaringen middels een comment op dit artikel.

Categories: Blogs

What is Job Security, as a Developer?

Derick Bailey - new ThoughtStream - Wed, 06/22/2016 - 13:30

It’s a question that a lot of people ask, and one that comes up in the movie “Office Space” where the characters are talking about the idea of ending up working at the same job for 20 or 30 years.

“I would love that kind of job security” was the response from one character.

And it’s a question that developers often face, in a market where it’s unusual to stay at a job for more than 2 to 4 years.

What Is Job Security?

As a developer that has more jobs on my resume than I can remember, it’s a question I’ve often asked. In spite of my constant movement between jobs (and clients), though, I consider my career to be very stable – to have high job security.

So… what is job security?

Watch this episode of Thoughts On Code to hear what I think it is.

Categories: Blogs

How Can UX work with Agile Teams

TV Agile - Tue, 06/21/2016 - 15:22
We will start off by explaining a fairly traditional way of development teams working with UX. After this we will explain the current viewpoint of most Agile UX people. Finally we will end by explaining how Lean UX proposes a shift in mindset and a totally different way of working. We will also give tips […]
Categories: Blogs

5 Fallacies of Enterprise Agile Transformation

Leading Agile - Mike Cottmeyer - Tue, 06/21/2016 - 13:50

I recently wrote a blog post addressing the fallacy that Project Managers are not needed in Enterprise Agile transformations. Reflecting on that post, it got me thinking about other misconceptions I’ve seen and am regularly asked about by my clients.  Here are the ones I hear the most, and my attempt to clear up some common misconceptions.

Fallacy #1: “We don’t need documentation, we’re Agile!”

This fallacy I hear all the time.  It stems from the Agile Manifesto value “Working Software over Comprehensive Documentation”.  Many people read that and believe that we just want to code and not provide documentation.  What this actually means that it is more valuable to see working, tested software instead of spending a lot of time documenting up front.  It DOES NOT mean no documentation.

Enterprise Agile Transformation Fallacies

In many organizations, long-lived documentation is important.  It lives beyond initiatives to provide value in the future.  This value can be in personas, meeting audit requirements, understanding design decisions or system requirements.  Documentation can also be embedded in code, in automation and test cases, or in visual specifications.  The important thing I coach is to focus on providing documentation that is barely sufficient.  The goal is enough documentation to provide a shared understanding and no more.  Anything beyond that tends to not be useful.  No one is going to read giant documents that sit on the shelf gathering dust!

Fallacy #2: “Agile means we will be faster from day 1!”

I hear this one often as transformations begin.  Clients will try to compare what they completed in a year pre-Agile to what they are delivering now.  This, of course, is trying to compare apples and oranges.

Enterprise Agile Transformation Fallacies

What Agile does a good job of is focusing on delivering the most valuable work first and driving risk down early (instead of waiting until the end of the project).  We don’t want to try to deliver everything we did last year.  We want to deliver the highest value items quickly and use feedback to course correct.

Over time, stable teams, automation, and process improvements will make teams faster.  But, you may actually feel like you’re slowing down in the beginning.  Focusing on value prioritization and high quality reduces rework and gets your product to market faster.

Fallacy #3: “It’s been 3 months…we’re done!”

Enterprise Agile Transformation Fallacies

Repeat after me, “My Agile Transformation will never be done!”  This is an important concept to understand. You will always be assessing.  You will always be improving.  It is a continuous cycle that never ends.

The world is advancing at an incredibly rapid pace.  If you stop to rest on your laurels, someone will pass you by – and you could be synonymous with “Blockbuster” or “Kodak”.  One of the key concepts we implement is sustainability of your transformation.  Many Agile transformations fail because they don’t have the internal support and mechanisms to progress forward beyond the initial stages.  This is the new way of life!

Fallacy #4: “We will never be able to deliver in 2 weeks!”

Enterprise Agile Transformation Fallacies

If you are traditional waterfall organization, going from 8-12 month release cycles to 2-weeks Sprints can seem daunting or downright impossible.  You can absolutely get there, but it won’t happen overnight.

Enterprise Agile transformations take time.  And you will need help.  Defining an end state vision, implementing a structure, governance, and metrics will set you on your path.  Form, train, and coach teams in agile practices will begin to change the way you deliver.  Use metrics to assess your system of delivery and make changes to reduce your batch sizes and optimize flow of value.  Begin automation and DevOps efforts and identify and decouple your dependencies.

As you implement change, you will see progress.  True transformation is a journey, but it can be done!

Fallacy #5: “We can still do what we’ve always done, just in an Agile way!”

Change is hard. It can be uncomfortable. When things get stressful, we want to revert to we are comfortable doing. But, if that worked, why are you transforming?

Enterprise Agile Transformation Fallacies

We’ve all heard the definition of insanity – “Doing the same thing over and over while expecting a different result.”  Real change is going to mean doing things differently. It doesn’t need to be many changes all at once. In fact, I like to make small changes, measure progress, and adapt to things that are not working.

At scale, we can’t be Agile by being structured the same way.  It is going to require change, organized around products or value, bringing people together on cross-functional teams, breaking down work into smaller increments.

Remember, we’re cultivating something special when we adopt Agile. Reverting back to your old ways of working will diminish your results and produce bad habits. Make sure you have a clear vision, defined end-state, and good communication as to why it is urgent to truly drive change. Focusing on the “Why” will help align the organization behind that change.

The post 5 Fallacies of Enterprise Agile Transformation appeared first on LeadingAgile.

Categories: Blogs

Strategy Deployment and Agendashift

AvailAgility - Karl Scotland - Tue, 06/21/2016 - 11:19

Agendashift is the approach used by Mike Burrows, based on his book Kanban from the Inside, in which he describes the values behind the Kanban Method. You can learn more by reading Mike’s post Agendashift in a nutshell. As part of his development of Agendashift, Mike has put together a values based delivery assessment, which he uses when working with teams. Again, I recommend reading Mike’s posts on using Agendashift as a coaching tool  and debriefing an Agendashift survey if you are not familiar with Agendashift.

After listening to Mike talk about Agendashift at this year’s London Lean Kanban Day I began wondering how his approach could be used as part of a Strategy Deployment workshop. I was curious what would happen if I used the Agendashift assessment to trigger the conversations about the elements of the X-Matrix model. Specifically, how could it be used to identify change strategies, and the associated desired outcomes, in order to frame tactics as hypotheses and experiments. Mike and I had a few conversations, and it wasn’t long before I had the opportunity to give it a go. This is a description of how I went about it.

Assessment & Analysis

The initial assessment followed Mike’s post, with participants working through individual surveys before spending time analysing the aggregated results and discussing strengths, weaknesses, convergence, divergence and importance.


Having spent some time having rich conversations about current processes and practices, triggered by exploring various perspectives suggested by the survey prompts and scores, the teams had some good insights about what they considered to be their biggest problems worth solving and which required most focus. Getting agreement on what the key problems that need solving are can be thought of as agreeing the key strategies for change.

Thus this is where I broke away from Mike’s outline, in order to first consider strategies. I asked the participants to silently and individually come up with 2 to 3 change strategies each, resulting in around 20-30 items, which we then collectively grouped into similar themes to end up with 5-10 potential strategies. Dot voting (with further discussion) then reduced this down to the 3 key change strategies which everyone agreed with.

To give some examples (which I have simplified and generalised), we had strategies around focussing collaboration, communication, quality, product and value.


Having identified these key strategies, the teams could then consider what desired outcomes they hoped would be achieved by implementing them. By answering the questions “what would we like to see or hear?” and “what would we measure?”, the teams came up with possible ways, both qualitative and quantitative, which might give an indication of whether the strategies, and ultimately the tactics, were working.

Taking the 3 key strategies, I asked small groups of 3-5 people to consider the outcomes they hope to achieve with those strategies, and then consolidated the output. One reassuring observation from this part of the workshop was that some common outcomes emerged across all the strategies. This means that there were many-to-many correlations between them, suggesting a messy coherence, rather than a simplistic and reductionist relationship.

Some examples of outcomes (again simplified and generalised) were related to culture, responsiveness, quality, understanding and feedback.


Once we have strategies and outcomes, the next step is to create some hypotheses for what tactics might implements the strategies to achieve the outcomes. To do this I tweaked Mike’s hypothesis template, and used this one:

We believe that <change>

implements <strategies>

and will result in <outcomes>

With this template, the hypotheses are naturally correlated with both strategies and outcomes (where the outcomes already consist of both subjective observations and objective measures).

I asked each participant to come up with a single hypothesis, creating a range of options from which to begin defining experiments.

For example (vastly simplified and generalised!):

We believe that a technical practice

implements a quality related strategy

and will result in fewer defects


This as far as we got in the time available, but I hope its clear that once we have hypotheses like this we can start creating specific experiments with which to move into action, with the possibility that each hypotheses could be tested with multiple experiments.


While we didn’t formally go on to populate an X-Matrix, we did have most of the main elements in place – strategies, outcomes and tactics (if we consider tactics to be the actions required to test hypotheses) – along with the correlations between them. Although we didn’t discuss end results in this instance, I don’t believe it would take much to make those explicit, and come up with the correlations to the strategies and outcomes.

On a recent call with Mike he described Agendashift in terms of making the agenda for change explicit. I think that also nicely describes Strategy Deployment, and why I think there is a lot of overlap. Strategy Deployment makes the results, strategies, outcomes and tactics explicit, along with the correlations and coherence between them, and it seems that Agendashift is one way of going about this.

Categories: Blogs

Agile and Scrum beyond Software Development

Ben Linders - Tue, 06/21/2016 - 09:43

Agile and Scrum Beyond Software Development - Ben LindersIn one of my workshops I explored how to use agile and Scrum beyond software development, for example in marketing, sales, support and in management. I gave this workshop in-house for a client to an audience which was not directly involved in software development. Many good ideas came up when preparing and giving this workshop, in this post I’m sharing them with the agile community.

Over the years I’m using agile principles and practices from Scrum beyond software development. For example, I do process improvement with agile, use Scrum for process improvementreduce process debt with agile, manage projects using agile, and use agile to prepare and give training and workshops. I wrote about the golden rules for agile process improvement. I was also involved in eduScrum, an initiative where Scrum is used by students for education at school.


Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

After giving a keynote at the 1st Conference in Melbourne I watched a talk from Eduardo Nofuentes about adopting agile beyond software. He slightly modified the agile manifesto to broaden it’s purpose while keeping the original thoughts:

We are uncovering better ways of working by doing it and helping others do it. Through this we have come to value:

Individual and interactions over processes and tools
Outcomes over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

I’m convinced that agile can be applied in many different areas. But, the information supporting this is scattered and sometimes hard to find, and that makes it difficult to use it and apply agile in other areas. Then the opportunity arose to bundle stuff … Help from the Scrum Master Community

A client asked me to give a workshop about agile to an audience which was outside software development. Explaining the agile manifesto and concepts from Scrum in my opinion wouldn’t be enough. I wanted to show actual examples of using agile beyond software, both from my own practice and cases published by others.

I used my network and posted a question on Facebook in the Scrum Master Community:

I’m preparing a workshop on agile/Scrum for non-IT. Anything that I should include, like experience reports, reference websites, checklists?

I got a lot of good ideas and experiences, which are in my workshop, next to what I do with agile and Scrum. In return for the contributions I promised to publish an overview of the workshop; to share an extract of my sheets which includes examples from using agile and Scrum beyond software development. Well, here it is:

Agile and Scrum beyond Software Development (overview) – Ben Linders from Ben Linders

A big thanks to everybody who provided ideas, on Facebook or directly, or by publishing examples on the internet on how they used agile and Scrum. All of this is very inspiring, and helped me to compile the sheets for the workshop which helped my client to take the first steps towards increasing their agility. Tailoring to use agile and Scrum beyond software

Of course you have to tailor agile and Scrum to support your needs. This is true when you use them in software development, but even more if using them beyond. Things to consider are:

  • Deliveries & Goal: What is it that you want to reach? Which agile principles and Scrum practices can help you to get there? How?
  • Custumers & stakeholders: Who do you have to involve to reach your goals and be able to deliver?
  • Team & collaboration: How do you want to work together? What needs to be arranged to make it possible?
  • Define “Done”: Which criteria need to be satisfied before something is good enough to deliver? Which existing processes and practices can be used?
  • How to get feedback: What can you do to know if you’re moving in the right direction (or not)? Which feedback do you need, from whom?

Summing up: Yes, you can certainly use agile and Scrum beyond Software Development. The agile mindset and principles are general enough to use them in many areas. Share your experiences!

There are many good examples available. I’ve listed the ones I know, but there are probably many more. Please share your experiences by commenting to this blog post if you have used agile and Scrum outside software development. Let’s collaborate to learn from each other, and help people around the world to improve their way of working using agile and Scrum!

Categories: Blogs

Links for 2016-06-20 []

Zachariah Young - Tue, 06/21/2016 - 09:00
Categories: Blogs

Performance, Not Policy

Evolving Excellence - Tue, 06/21/2016 - 00:01

No-PoliciesFew people realize how employee policy manuals, usually given to you on your first day and then mostly forgotten, shape an organization’s culture and thereby its fundamental performance.

To give you a reference point, one company I worked for had a forty-plus-page employee manual that started every section with “COMPLIANCE IS ESSENTIAL” highlighted in bold, with “required to conform” sprinkled liberally throughout the document. The manual ended with a meaty discussion of the punitive measures that would happen if someone deviated from the policies. And this was a company considered very innovative in many ways!

The other extreme is Zaarly, a San Francisco-based startup. Its employee handbook, posted online for even non-employees to see, talks directly about culture. The “Rules for Work” section begins with “We don’t have these.” And in a style prevalent throughout the document, it adds that “if you want to coast, we recommend you apply for a job at Craigslist.” Included are some good thoughts on teams, work, and communication, but no rules.

Another example is the famous Netflix “business culture” PowerPoint that serves as the company’s employee handbook. Similar to Zaarly’s handbook, it talks a lot about culture and a lack of rules. There is no vacation policy, and the travel and expense policy is literally five words: “Act in Netflix’s best interests.” That’s it. Unlike Zaarly, Netflix does say some rules are necessary, such as: “Absolutely no harassment of any kind.” In this case, I completely agree, especially on that item. Some topics relating to privacy, security, and regulatory requirements are important enough that they need to be spelled out in no uncertain terms.

Netflix believes high-performance people should be free to make decisions, and those decisions need to be grounded in context. Mission, vision, and value statements do not create context. To demonstrate this, Netflix’s presentation provides the example of how Enron’s value statement included “integrity.” Real company values are shown by who gets rewarded for embodying desired behaviors and skills. The document goes on to describe the primary Netflix values and the associated behaviors.

At Netflix, flexibility is more important over the long term than efficiency. To inhibit the chaos that too much flexibility in a large organization can create, the company hires (and keeps) only high-performance people. High-performance people make great decisions, so building a staff of them is better than having people who are good at following lists of rules. Later on in the Netflix document, there is a good discussion that encourages managing with context instead of trying to control people. That way, when something fails, managers look to figure out what went wrong with the process rather than with the people.

One part of the Netflix document that gave me pause was an insinuation that defined processes (such as standard work) are all bad. But doing standard work doesn’t necessarily mean the employee has zero flexibility. As those of us in the Lean world know, standard work is the foundation for kaizen. Once an employee deeply understands a process, he or she can (and is expected to) come up with ways to improve it and then share it, which is called yokoten.

Gemba Academy has adopted many similar concepts in our own Gemba Academy Culture Code.

In January 2014, Brad Power posted a piece in Harvard Business Review titled Drive Performance by Focusing on Routine Decisions that hits at a similar concept. Instead of creating rule-bound defined processes, companies should focus on improving the quality of the decisions made by managers. Power illustrates the idea with an example those of us in the manufacturing world have all experienced: the maelstrom of materials control. He describes how the materials department of an electronics distributor was able to improve operations by better training managers to make key decisions about inventory. The goal of the training was to get managers to focus less on perfecting company processes (the “box and arrows” of a flowchart) and more on understanding what objectives the processes were supporting in the first place. When managers were able to understand how the processes affected actual business performance, they were able to make decisions (the “diamonds and arrows”) that improved performance:

These two stories highlight the advantages of focusing process improvement on “diamonds and arrows” — i.e., making better decisions. Project leaders who focus exclusively on the “boxes and arrows”of workflow action improvement will often find themselves caught up fixing yesterday’s operations and systems issues. Workers who participate in these interviews and workshops tend to fixate on the pain points they want fixed. This focus on immediate problems can actually distract the project team from the real goals of the business and the decisions that will help achieve them.

Are your rules improving the boxes (company processes) but harming the diamonds (managers’ decision-making)? How is that rigidity affecting your long-term performance? Do you have a team of high-performance people that you can trust to deal with the diamonds in a flexible, agile way? And how do your under-lying documents, even down to the employee handbook, support or impede that? These are questions to consider as you look to improve your company’s performance.

Categories: Blogs