Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Process Management

Biases Affecting Perception and Decision Making

What you see is dependent on what you expect.

What you see depends on what you expect.

Cognitive biases are a pattern of behavior that reflects a deviation in judgment that occurs under particular situations. Biases develop as filters or shortcuts that help us perceive information quickly in a manner that turns out to be beneficial to a decision-making process. Biases that help us recognize patterns helped early humans stay alive by recognizing predators. The shortcut kept our ancestors alive even if there were false positives (you can survive lots of false positives, but you aren’t likely to survive a false negative). Project teams (Agile or not) use or fall prey to a wide range of biases that affect perceptions and decisions. A sample of common biases that affect project teams in this category include:

Anchor bias refers to the tendency to rely heavily on one piece of information when making decisions. This bias is often seen when early estimates for a project or a tasks are made. The instant they are placed on the table they become a reference point to which all changes will be compared.

Clustering illusion (or clustering bias) is the tendency to see patterns in clusters or streaks of in a smaller sample of data inside larger data sets. For example, a team I recently worked with had an average velocity of 30 story points per sprint (ranged between 20 – 36) had three sprints in a row that delivered 40+ story points. While nothing significant had changed with how the team was working, outsiders saw a pattern and believed something out of the ordinary was occurring. (FYI – if there is no statistical significance to the data what we are seeing is “common cause” variance.)

The curse of knowledge bias generates a filter that blocks the ability think about a topic from a different and generally less informed perspective. In many cases being an expert on a topic makes it very difficult to see an out-of-the-box solution. This is one of the reasons significant changes in IT platforms or concepts come as new players enter the organization that have less experience with current tools and techniques. In a similar manner to the curse of knowledge, the status quo bias or the tendency to want things to stay relatively the same, creates a perception filter that helps the individual or team seek out and fixate data and concepts which makes them comfortable so they do not need to change.

An availability cascade causes a concept to become more and more plausible the more it is repeated publicly.  An availability cascade generates a self-reinforcing feedback loop. Perhaps that is why Pokemon became more popular the more it was shown on the Cartoon Network. Daniel Pink, author of To Sell Is Human, in a Salesforce.Com webinar on July 9th pointed out that repetition increases process fluency, which makes the repeated item seem to be more true through repetition. Sales, marketing and 24 hour news channels understand and use the availability cascade bias to great effect.

A final example of biases that affect behavior and perception is optimism bias. Optimism bias is the tendency to be overoptimistic about favorable outcomes. This bias is often exhibited in status reports or in promises made early in a project. These are generally not lies, but rather due to optimism bias we believe that we can deliver. Dr. Ricardo Validri in Software Process and Measurement Cast 84 suggests that optimism bias is one of major reasons IT personnel are poor estimators.

This is a sample of cognitive biases that affect how we perceive information and then how we make decisions. Each of the biases reflects some basic component of human psychology and has been found to be generally beneficial. However all biases can create blind spots. A good coach or leader will first be aware of his or her biases and then help the team understand their blind spots while not abandoning the shortcuts that can help us perceive what is important and make timely decisions.


Categories: Process Management

Microservices Architecture Principle #3: small bounded contexts over one comprehensive model

Xebia Blog - Wed, 05/27/2015 - 21:18

Microservices are a hot topic. To help organizations make the best of this new architectural style Xebia has defined a set of principles that we feel should be applied when implementing a Microservice Architecture. Over the next couple of days we will cover each of these principles in more detail in a series of blog posts. Today we discuss the Domain Driven Design (DDD) concept of "Bounded Context" and how it plays a major role in designing Microservices.

One of the discussion points around Microservices, since the term was coined in 2013, is how big (or rather, how small) a Microservice should be. Some people, such as Fred George, claim services should be small, maybe between 100-1000 lines of code (LoC). However, LoC is a poor metric for measuring software in general and even more so for determining the scope of a Microservice. Rather, when identifying the scope of our Microservices, we look at the functionality that a service needs to provide, and how the service relates to other services. Our aim is to design Microservices that are autonomous, ie. have a low coupling with other services, have well defined interfaces, and implement a single business capability, ie. have high cohesion.

A technique that can be used for this is "Context Mapping".  Via this technique we identify the various contexts in the IT landscape and their boundaries. The Context Map is the primary tool used to make boundaries between domains explicit. A Bounded Context encapsulates the details of a single domain, such as domain model, data model, application services, etc., and defines the integration points with other bounded contexts/domains. This matches perfectly with our definition of a Microservice: autonomous, well defined interfaces, implementing a business capability. This makes Context Mapping (and DDD in general) an excellent tool in the architects toolbox for identifying and designing Microservices.

Another factor in sizing our services is that we would like to have models that can "fit in your head", so as to be able to reason about them efficiently. Most projects define a single comprehensive model encompassing the full domain, as this seems natural, and appears easier to maintain as one does not have to worry about the interaction between multiple models, or translate from one context to the other.

For small systems this may be true, but for large systems the costs will start to outweigh the benefits: maintaining a single model requires centralization. Naturally the model will tend to fragment: a domain expert from the accounting domain will think differently about 'inventory' than a logistics domain expert, for example. It requires lots of coordinated efforts to disambiguate all terms across all domains. And worse, this 'unified vocabulary' is awkward and unnatural to use, and will very likely be ignored in most cases. Here bounded contexts will help again: they make clear where we can safely use the natural domain terms and where we will need to bridge to other domains. With the right boundaries and sizes of our bounded contexts we can make sure our domain models "fit in your head" and that we do not have to switch between models too often.

So maybe the best answer to the question of how big a Microservice should be is: it should have a well defined bounded context that will enable us to work without having to consider, or swap, between contexts.

Readers and Listeners!

Part of the enjoyment of publishing the Software Process and Measurement Blog and Podcast is interacting with my listeners, readers and interviewees!

Contests on the blog are one of the ways we provide the listener’s with a little bit of lagniappe. The Software Process and Measurement Cast 330 features an interview with Anthony Mersino. The interview about Agile, coaching, organizational change AND his new book Agile Project Management  provided great advice to the podcast listeners. In a great gesture,  Anthony sponsored a contest for copy of his book. The winner is Paul Laberge! Paul is a long time reader of the blog and listener to the podcast (and frequently writes to discuss ideas or to argue about cell phone operating systems). Here is a picture of Paul and his new book.

Untitled1

Paul, thank you for being part of both the podcast and the blog! Anthony, thank you for providing the book and the contest! Interested in doing a review Paul?

On another front, recently I attended the CMMI® Global Conference and met Hiroshi Kobayashi. Hiroshi is also a listener, reader and often comments on the blog. I find it incredible to meet people in person that I interact with on the podcast and blog. Interacting with members of the SPaMCAST community keeps me motivated. Here is a picture of Hiroshi and myself (thanks to Paul Byrnes for taking the picture).

Untitled

Hiroshi is a Senior Executive Manager of the CMMI Consulting Division at System Information Company in Japan. He is also PMI certified Project Management Professional and a Scrum Alliance Certified Scrum Master.

Hiroshi, I look forward to collaborating on the blog and podcast!

A message to all readers and listeners! If you are going to be at ICEAA in June 9 -12 in San Diego, please let me know or find me at the conference. I would like to me you in person, hear your story, talk about ideas, concepts and even the weather!

My sincere thanks to Paul, Hiroshi and ALL of my readers and listeners. Interacting with you enriches my blogging and podcasting experience and I hope it enriches yours!


Categories: Process Management

Staying Ahead of the Curve

From the Editor of Methods & Tools - Tue, 05/26/2015 - 15:45
We all want to stay ahead of the curve – after all, that’s what you go to a conference for. But have you ever considered how being ahead of the curve might be dangerous? Using a new language before you understand it, putting a technology into production so you can learn it, abandoning “old practices” […]

Product Backlog Refinement (Grooming)

Mike Cohn's Blog - Tue, 05/26/2015 - 15:00

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

Product backlog refinement—sometimes called product backlog grooming in reference to keeping the backlog clean and orderly—is a meeting that is held near the end of one sprint to ensure the backlog is ready for the next sprint.

During a product backlog refinement meeting, the team and product owner discuss the top items on the product backlog. The team is given a chance to ask the questions that would normally arise during sprint planning:

  • What should we do if the user enters invalid data here?
  • Are all users allowed to access this part of the system?
  • What happens if…?

By asking these questions earlier, the product owner is given a chance to arrive at answers to any questions he or she may not be prepared to answer immediately.

If those questions were asked for the first time in sprint planning, and too many could not be answered, it might be necessary to put a high-priority product backlog item aside and not work on it during the sprint.

These questions do not need to be fully resolved in a backlog refinement meeting. Rather, the product owner needs only to address them just enough so that the team feels confident that the story can be adequately discussed during the coming planning meeting.

Backlog refinement in that sense is really a checkpoint rather than an effort to fully resolve issues.

I like to hold the product backlog refinement meetings three days before the end of the current sprint. This gives the product owner sufficient time to act on any issues that are identified. Some teams find that doing shorter meetings every week rather than once per sprint are more suited to their cadence, and that is, of course, fine.

Unlike other Scrum meetings, I do not think the product backlog refinement meeting requires the participation of the whole team.

If you think about a whole team meeting three days before the end of the sprint, there is likely to be someone who will be frantically busy—someone who, if forced to attend one more meeting, may have to work late to finish the work of the sprint.

I’d prefer to conduct the meeting without such team members. As long as the same team members don’t miss the meeting each sprint, I think it’s fine to conduct backlog refinement meetings with about half the team plus the product owner and ScrumMaster.

Quickly build a XL Deploy plugin for deploying container applications to CoreOS

Xebia Blog - Mon, 05/25/2015 - 21:57

You can use fleetctl and script files to deploy your container applications to CoreOS. However, using XL Deploy for deployment automation is a great solution when you need to deploy and track versions of many applications. What does it take to create a XL Deploy plugin to deploy these container applications to your CoreOS clusters?

XL Deploy can be extended with custom plugins which add deployment capabilities. Using XL Rules custom plugins can be created quickly with limited effort. In this blog you can read how a plugin can be created in a matter of hours.

In a number of blog posts, Mark van Holsteijn explained how to create a high available Docker container platform using CoreOS and Consul. In these posts shell scripts (with fleetctl commands) are used deploy container applications. Based on these scripts I have built a XL Deploy plugin which deploys fleet unit configuration files to a CoreOS cluster.

 

Deploying these container applications using XL Deploy has a number of advantages:

  • Docker containers can be deployed without creating, adjusting and maintaining scripts for individual applications.
  • XL Deploy will track and report the applications deployed to the CoreOS clusters.
  • Additional deployment scenarios can be added with limited effort.
  • Deployments will be consistent and configuration is managed across environments.
  • XL Deploy permissions can be used to control (direct) access to the CoreOS cluster(s).

 

Building an XL Deploy plugin is fast, since you can:

  • Reuse existing XL Deploy capabilities, like the Overthere plugin.
  • Utilize XL Deploy template processing to inject property values in rules and deploy scripts.
  • Exploit the XL Deploy unified deployment model to get the deltas which drive the required fleetctl deployment commands for any type of deployment (new, update, undeploy and rollback deployments).
  • Use xml and script based rules to build deployment tasks.

Getting started

  • Install XL Deploy, you can download a free edition here. If you are not familiar with XL Deploy, read the getting started documentation.
  • Next add the plugin resources to the ext directory of your XL Deploy installation. You can find the plugin resources in this Github repository. Add the synthetic.xml, xl-rules.xml file from the repository root. In addition, add the scripts directory and its contents. Restart XL Deploy.
  • Next, setup a CoreOS cluster. This blog post explains how you can setup such a platform locally.
  • Now you can connect to XL deploy using your browser. On the deployment tab you can import the sample application, located in the sample-app folder of the plugin resources Github repository
  • You can now setup the target deployment container based on the Overthere.SshHost configuration item type. Verfiy that you can connect to your CoreOS cluster using this XL Deploy container.
  • Next, you can setup a XL Deploy environment, which contains your target deployment container.
  • Now you can use the deployment tab to deploy and undeploy your fleet configuration file applications.

 

Building the plugin

The plugin consists of two xml files and a number of script files. Below you find a description of the plugin implementation steps.

The CoreOS container application deployments are based on fleet unit configuration files. So, first we create a XL Deploy configuration Item type definition which represents such a file. This XL Deploy deployed type is defined in the XL Deploy synthetic.xml file. The snippet below shows the contents of this file. I have assigned the name “fleet.DeployedUnit”.

synthetic

The definition contains  a container-type attribute. The Overthere.SshHost container is referenced. The plugin can simple use the Overthere.SshHost container type to connect to the CoreOS cluster and to execute fleet commands.

Furthermore, I have added two properties. One property which can be used to specify the number of instances. Note that XL Deploy dictionaries can be utilized to define the number of instances for each environment separately. The second property is a flag which controls whether instances will be started (or only submitted and loaded).

If you want to deploy a fleet configuration file using fleetctl, you can issue the following three commands: submit, load and start. In the plugin, I have created a separate script file for each of these fleetctl commands.  The caption below shows the script file to load a fleet configuration file. This load script uses the file name property and numberOfInstances property of the “fleet.DeployedUnit” configuration item.

load-unit

Finally, the plugin can be completed with XML-based rules which create the deployment steps. The caption below shows the rule which adds steps to [1] submit the unit configuration and [2] load the unit when (a version of ) the application is deployed.

rules-xldeploy

Using rules, you can easily define logic to add deployment steps. These steps can closely resemble the commands you perform when you are using fleetctl. For this plugin I have utized xml-based rules only. Using script rules, you can add more intelligence to your plugin. For example, the logic of the restart script can be converted to rules and more fine grained deployment steps.

More information

If you are interested in building your own XL Deploy plugin, the XL Deploy product documentation contains tutorials which will get you started.

If you want to know how you can create a High Available Docker Container Platform Using CoreOS And Consul, the following blogs are great starting point:

Microservices architecture principle #2: Autonomy over coordination

Xebia Blog - Mon, 05/25/2015 - 16:13

Microservices are a hot topic. Because of that a lot of people are saying a lot of things. To help organizations make the best of this new architectural style Xebia has defined a set of principles that we feel should be applied when implementing a Microservice Architecture. Over the next couple of days we will cover each of these principles in more detail in a series of blog posts.
This blog explains why we prefer autonomy of services over coordination between services.

Our Xebia colleague Serge Beaumont posted "Autonomy over Coordination" in a tweet earlier this year and for me it summarised one of the crucial aspects for creating an agile, scalable and robust IT system or organisational structure. Autonomy over coordination is closely related to the business capabilities described in the previous post in this series, each capability should be implemented in one microservice. Once you have defined your business capabilities correctly the dependencies between those capabilities are minimised. Therefore minimal coordination between capabilities is required, leading to optimal autonomy. Increased autonomy for a microservice gives it freedom to evolve without impacting other services: the optimal technology can be used, it can scale without having to scale others, etc. For the team responsible for the service the advantages are similar, the autonomy enables them to make optimal choices that make their team function at its best.

The drawbacks of less autonomy and more coordination are evident and we all have experienced these. For example, a change leads to a snowball of dependent changes that must be deployed at the same moment, making changes to a module requires approval of other teams,  not being able to scale up a compute intensive function without scaling the whole system, ... the list is endless.

So in summary, pay attention to defining you business capabilities (microservices) in such a manner that autonomy is maximised, it will give you both organisational and technical advantages.

SPaMCAST 343 - Commitment In Agile Revisited, Hiring in Software

Software Process and Measurement Cast - Sun, 05/24/2015 - 22:00

Software Process and Measurement Cast 343 includes two features.  The first is our essay, Commitment, Revisited: Is Commitment Anti-Agile?  We think not!  Commitment is a core behavior for delivering business value effectively.

Our second feature is a visit from the Software Sensei, Kim Pries.  Kim reflects on hiring practices for software development.  Among the nuggets from Kim is the reminder to keep in mind that the perfect employee does not exist, and you are unlikely to ever find someone who fulfills every item on your job description.  How does that simple fact impact hiring?

A Call to action!

Reviews of the Podcast help to attract new listeners.  Can you write a review of the Software Process and Measurement Cast and post it on the podcatcher of your choice?  Whether you listen on ITunes or any other podcatcher, a review will help to grow the podcast!  Thank you in advance!

Re-Read Saturday News

The Re-Read Saturday focus on Eliyahu M. Goldratt and Jeff Cox’s The Goal: A Process of Ongoing Improvement began on February 21nd. The Goal has been hugely influential because it introduced the Theory of Constraints, which is central to lean thinking. The book is written as a business novel. Visit the Software Process and Measurement Blog and catch up on the re-read.

Note: If you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast.

Dead Tree Version or Kindle Version 

Our next re-read is The Mythical Man-Month Get a copy now and start reading!We will start in 4 weeks!

Upcoming Events

2015 ICEAA PROFESSIONAL DEVELOPMENT & TRAINING WORKSHOP
June 9 – 12
San Diego, California
http://www.iceaaonline.com/2519-2/
I will be speaking on June 10.  My presentation is titled “Agile Estimation Using Functional Metrics.”

Let me know if you are attending!

Also upcoming conferences I will be involved in include and SQTM in September. More on these great conferences next week.

Next SPaMCast

The next Software Process and Measurement Cast will feature our conversation with Susan Parente.  We talked about Agile risk management.  If you do not have a plan to address risk, you are asking for risk to transform into pain for you and everyone around you.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese._

Categories: Process Management

SPaMCAST 343 – Commitment In Agile Revisited, Hiring in Software

 www.spamcast.net

http://www.spamcast.net

Listen Now

Subscribe on iTunes

Software Process and Measurement Cast 343 includes two features.  The first is our essay, Commitment, Revisited: Is Commitment Anti-Agile?  We think not!  Commitment is a core behavior for delivering business value effectively.

Our second feature is a visit from the Software Sensei, Kim Pries.  Kim reflects on hiring practices for software development.  Among the nuggets from Kim is the reminder to keep in mind that the perfect employee does not exist, and you are unlikely to ever find someone who fulfills every item on your job description.  How does that simple fact impact hiring?

A Call to action!

Reviews of the Podcast help to attract new listeners.  Can you write a review of the Software Process and Measurement Cast and post it on the podcatcher of your choice?  Whether you listen on ITunes or any other podcatcher, a review will help to grow the podcast!  Thank you in advance!

Re-Read Saturday News

The Re-Read Saturday focus on Eliyahu M. Goldratt and Jeff Cox’s The Goal: A Process of Ongoing Improvement began on February 21nd. The Goal has been hugely influential because it introduced the Theory of Constraints, which is central to lean thinking. The book is written as a business novel. Visit the Software Process and Measurement Blog and catch up on the re-read.

Note: If you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast.

Dead Tree Version or Kindle Version 

Our next re-read is The Mythical Man-Month Get a copy now and start reading!We will start in 4 weeks!

Upcoming Events

2015 ICEAA PROFESSIONAL DEVELOPMENT & TRAINING WORKSHOP
June 9 – 12
San Diego, California
http://www.iceaaonline.com/2519-2/
I will be speaking on June 10.  My presentation is titled “Agile Estimation Using Functional Metrics.”

Let me know if you are attending!

Also upcoming conferences I will be involved in include and SQTM in September. More on these great conferences next week.

Next SPaMCast

The next Software Process and Measurement Cast will feature our conversation with Susan Parente.  We talked about Agile risk management.  If you do not have a plan to address risk, you are asking for risk to transform into pain for you and everyone around you.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.


Categories: Process Management

Microservices architecture principle #1: Each Microservice delivers a single complete business capability

Xebia Blog - Sat, 05/23/2015 - 21:13

Microservices are a hot topic. Because of that a lot of people are saying a lot of things. To help organizations make the best of this new architectural style Xebia has defined a set of principles that we feel should be applied when implementing a Microservice Architecture. Over the next couple of days we will cover each of these principles in more detail in a series of blog posts.
This blog explains why a Microservice should deliver a complete business capability.

A complete business capability is a process that can be finished consecutively without interruptions or excursions to other services. This means that a business capability should not depend on other services to complete its work.
If a process in a microservice depends on other microservices we would end up in the dependency hell ESBs introduced: in order to service a customer request we need many other services and therefore if one of them fails everything stops. A more robust solution would be to define a service that handles a process that makes sense to a user. Examples include ordering a book in a web shop. This process would start with the selection of a book and end with creating an order. Actually fulfilling the order is a different process that lives in its own service. The fulfillment process might run right after the order process but it doesn’t have to. If the customer orders a PDF version of a book order fulfillment may be completed right away. If the order was for the print version, all the order service can promise is to ask shipping to send the book. Separating these two processes in different services allows us to make choices about the way the process is completed, making sure that a problem or delay in one service has no impact on other services.

So, building a microservice such that it does a single thing well without interruptions or waiting time is at the foundation of a robust architecture.

Re-Read Saturday: The Goal: A Process of Ongoing Improvement. Part 14

IMG_1249

I recently had a long discussion about whether it was more important to solve an urgent and specific business problem or to create a culture of process improvement that would avoid crises in the future. My colleague described the immediate problem as threatening to the entire organization. The obvious answer was that the immediate problem needed to be addressed. The question then became whether consultants should be engaged to provide the answer or to help the organization discover the answer. I suggest that doing the later actually negates the first question by generating a solution to the immediate problem while creating a culture of process improvement. Johan in The Goal illustrates this nicely. He helped Alex and his management team discover the answer while building a culture of process improvement.

Part 1       Part 2       Part 3      Part 4      Part 5      Part 6      Part 7      Part 8    Part 9   Part 10   Part 11  Part 12
Part 13

Chapter 33 begins with Alex working on assembling his new team. He begins with Lou, the plant accountant. Before Alex can ask him to come with him, Lou explains to Alex that another old measurement has been causing problems with how the plant is perceived and how it behaves. Inventory is accounted for as asset on the balance sheet even though inventory is a liability. Since the plant has become more efficient it is carrying less inventory therefore reducing the assets reported on the balance sheet. During the period of time that inventory was drawn down to the levels needed by the more efficient process the plant looked as if it was increasing the amount of liabilities. Now that a new equilibrium in inventory had been established the problem was not an issue, however Lou notes that, “measurement should induce the parts [of the process} to do what is good for the organization as a whole.” Lou is ready to help Alex and is pumped to focus on building a better measurement program.

Alex approaches Bob Donavan, the plant production manager, to become the division’s production manager. Bob points out that the Burnside order that sealed Alex’s new deal was engineered. Alex and his management team had not just “taken” the order, but rather had worked out the best way the order could be delivered and then had negotiated a deal that benefited everyone. Bob wants to find a way create and document a process in which the plant and engineering can be an integral sales. A process and documentation is needed so that the plant leadership team does not need to be intimately involved in every order. Bob Donavan wants to stay at the plant and become the new plant manager and wants Stacey in materials to become the new production manager.

They find Stacey working on a new potential problem. Stacey has identified that there is a class of resources called capacity constraints resources (CCRs). CCRs are resources that have constraints, but are not bottlenecks. As the processing of work through bottlenecks is improved, CCRs risk becoming bottlenecks which Will negatively impact produvtuvity. Process improvements need to be continually be made across the entire system.

Alex finally turns to Ralph. Ralph points out that he now feels like he is an important part of the team rather than just the computer nerd in the corner. He walks Alex through his ideas of building systems to support engineering, managing buffers and for better measurement.

The experimentation that led to changing how the plant works has changed how Alex’s management team thinks about their jobs. Asking questions and experimenting with changes to the process those questions generate has yielded a much higher level of involvement and commitment.

Chapter 34 jumps to Alex and Julie sitting their kitchen drinking tea. They are discussing how each of Alex’s current team is exploring ideas that might not have an answer. Julie points out that if Johan had not cut him off by suggesting he trust his own judgement Alex might be reaching out to Johan for suggestions rather than trying to work on them as a team.

The discussion of Johan brings them back to Johan’s last question to Alex. Johan had asked, “What  are the techniques needed for management?” Julie suggests that since the questions that Alex’s management team each is currently working on will be around after Alex moves to his new job, why not engage them in answering Johan’s question. They have as much of a stake in the answer as Alex does!

Alex pulls the team together and they spend their first session discussing and drawing the many ways Alex could determine what is going on when he start the new job. There are many ways to answer the question of what is going on. Each yields a different answer based on differences in perspective, approach and an arbitrary order of arranging the results. The wide range of ways to think about the problem make it difficult to actually determine a solution. The group agrees to meet the next day.

Chapters 33 and 34 reflect a shift of focus. With the plant saved, Alex is faced with a need to generalize the process that was used so that it can be used for different problems or scaled up to the next level based on his promotion.

Remember that the summary of previous entries in the re-read of The Goal have been shifted to a new page (here).   Also, if you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast. Dead Tree Version or Kindle Version


Categories: Process Management

Constraints on the use of Dunbar’s Number

17322084523_7ce372fd98_oDunbar’s number represents a theoretical limit on the number of people in a group that can maintain stable social relationships. Stable social relationships are needed to support application of Agile values, principles and techniques. Dunbar’s number is often quoted as 150 people. However, the limit for any individual group is a not only a reflection limits like Dunbar’s number but also context. If we accept there is some theoretical limit that we can’t scale past such as Dunbar’s number, we need to ask how other project or environmental factors further constrain the maximum number of people working on a problem.  Why go to the trouble of scaling up the number of people working a problem? Many Agilistas would suggest that a single small team is optimal. However, many problems will require a larger collation of teams to deliver value and functionality. Additional contextual drivers that modify the theoretical maximum number of people in a group or a team-of-teams include at least four factors. They are:

  1. Cohesion, or how well people stick together. There are many attributes that can generate cohesion. Examples include: big ideas, goals, nationalities, religions and even corporate identities. Cohesion fosters a common relationship, which helps make groups more willing to put forth effort to achieve an end. For example, it often is hard to achieve a cohesive group when members come from multiple external consultancies. Each organization involved in the group have a different set of organizational goals that will reduce cohesion unless they are subjugated to the project goal.  Reducing the number of people below Dunbar’s number makes the use of techniques like peer pressure to institutionalize a project vision to increase cohesion easier.
  2. Complexity is a measure of the number of properties for a project that are outside of the norm. The complexity of a problem reduces the optimal maximum number of people that can be bear because complexity generally requires either more control and coordination or alternately smaller teams to ensure collaboration.
  3. Uncertainty occurs when teams are searching for an answer to a business or technical problem. When a team needs to tackle an unknown business problem or new technology research is often required. Research generally is constrained to small teams with specialized skills reducing the optimal maximum group size for this type of endeavor well below Dunbar’s number. As concepts and ideas are discovered they can be rolled out more broadly to be fleshed out, prototyped and implemented increasing the group working on the project closer to Dunbar’s number.
  4. Dependencies between components often mean that work needs to be single threaded (or at least spread less broadly). Dependencies reduce the number of people or teams that can be effectively leveraged.

The idea of increasing the number of people and teams working on a project often appears to be a mechanism for delivering value more quickly. When adding people to is suggested remember the number of people working on a problem is a constraint than can not be dealt with by linearly increasing the number of people applied to a problem until you reach a limit such as Dunbar’s number.  Context directly impacts how large any group can before overhead and other constraints reduce effectiveness.    It is often said that you can’t get nine women to have a baby in a month. In addition to Dunbar’s number, context plays an important role in defining overall team size.


Categories: Process Management

Software Development Linkopedia May 2015

From the Editor of Methods & Tools - Wed, 05/20/2015 - 15:24
Here is our monthly selection of knowledge on programming, software testing and project management. This month you will find some interesting information and opinions about Agile software development, giving feedback, managing technical debt, normalizing user stories, dependency injection, developer griefs, behavior driven development (BDD) and software architecture. Web site: The GROWS Method Blog: The Failure […]

Scaling Agile: Dunbar’s Number

How many people is too many?

How many people is too many?

When determining how large an Agile program can be, one of the oft quoted “facts” is that the number of people involved in an Agile program is governed by Dunbar’s number. Dunbar’s number is the limit of the number of people in a group that can maintain stable social relationships. The term, social relationship is a reflection of regular interactions, the ability to recognize another member as part of the group or are committed to a common goal. These attributes are important to any project and are perhaps more important in Agile projects because they rely on team cohesion to minimize bureaucracy and control mechanisms.

The concept of Dunbar’s number is based on research originally performed through the observations of primates and then extended to humans in the early 1990’s. In June of 1992, Robin Dunbar  published “Neocortex size as a constraint on group size in primates” in the Journal of Human Evolution (Volume 22, Issue 6, June 1992, Pages 469–493). In the paper Dunbar noted a correlation between the size of a primate brain and the average social group size. From the abstract, Dunbar wrote:

Group size is found to be a function of relative neocortical volume, but the ecological variables are not. This is interpreted as evidence in favour of the social intellect theory and against the ecological theories. It is suggested that the number of neocortical neurons limits the organism’s information-processing capacity and that this then limits the number of relationships that an individual can monitor simultaneously. When a group’s size exceeds this limit, it becomes unstable and begins to fragment. This then places an upper limit on the size of groups which any given species can maintain as cohesive social units through time.

While group size of 150 is often quoted as Dunbar’s number, 150 is an approximation. As noted in the “Limits of Friendship” by Maria Konnikova (October 7, 2014) Dunbar’s number can range from 100 – 200 (ish) people based on factors such a social gregariousness. Other limits of group size have also been published for example Drs. Peter Killworth and Russell Bernard have published numbers in excess of 200 people.

Based on Dunbar’s number, the Scaled Agile Framework Enterprise (SAFe) suggests that the largest Agile release train (ART) should include approximately 150 people. The ART is supported by a framework (SAFe), hierarchy (release train engineer and Scrum masters) and bureaucracy (product management and product owners). Agile being practiced by a single team of 5 – 9 people would not require this degree of overhead to ensure coordination.

Scaling agile is a balancing act between the efficiency of team-level Agile techniques and the concessions made to control when Agile is scaled up to deal with larger efforts. Historically, very large projects tend to be less efficient. Capers Jones in Applied Software Measurement, Third Edition[1] (p295) indicates that productivity falls for all types of projects as they exceed 1,000 function point points. Function points are an ISO standard method of measuring software size based on a standard set of rules. Simply put the larger a project is in function points the larger the team (or team of teams) needed to deliver the project which yields the need for more control processes all other things being equal. He further makes the point (p 307) that as project size increases, so does the probability of cancellation.

Scaling Agile leverages many of the techniques used by team-level Agile, such as small team size, small batch sizes and Scrum. These techniques are are very lean but are perceived limit the amount of value that can be delivered within a specific period of time. As Agile projects grow in size additional techniques are needed to maintain control. Dunbar’s number (or similar ideas) provides a limit to try to avoid letting a piece of work become too large to manage. The number act as limit to the number of people involved in a piece of work. Applying additional constraints, such as releases or SAFe’s program increment, add a dimension of time as constraint. The combination of constraints on the number of people and the how long those people will be working provide an explicit constraint on how much work can be delivered.

1 Applied Software Measurement, Third Edition, T. Capers Jones, McGraw Hill, 2008


Categories: Process Management

Variations in Iteration - New Lecture Posted

10x Software Development - Steve McConnell - Tue, 05/19/2015 - 18:26

I've posted this week's lecture in my Understanding Software Projects series at https://cxlearn.com. Most of the lectures that have been posted are still free. Lectures posted so far include:  

0.0 Understanding Sofware Projects - Intro

0.1 Introduction - My Background
     0.2 Reading the News

1.0 The Software Lifecycle Model - Intro
     1.1 Variations in Iteration (New this week) 
     1.2 Lifecycle Model - Defect Removal

2.0 Software Size

Check out the lectures at http://cxlearn.com!

Understanding Software Projects - Steve McConnell

 

Impostor Syndrome: Why Some ScrumMasters Feel Like They’re Faking It

Mike Cohn's Blog - Tue, 05/19/2015 - 15:00

Geoff Watts is one of the leading Scrum thinkers in the world, and one of the few to hold both the Certified Scrum Trainer and Certified Scrum Coach designation. In addition to his book, "Scrum Mastery: From, From Good To Great Servant-Leadership" Geoff has written a new book, "The Coach's Casebook". His new book is not specifically about Scrum or agile, but since a great deal of a ScrumMaster's job is indeed coaching a team to better performance, I think you'll find the book applicable to your work. In the following guest post, Geoff shares with a story about a feeling I think we can all relate to. I know I've felt the way he describes many times. --Mike Cohn

 

"One of these days, I'm going to be found out. They will realise I have no idea what I'm talking about and I'll be fired."

I remember standing in my kitchen 15 years ago saying these words to my wife. We were thinking about buying something for the house and I was worried that my position as a project manager wasn't secure enough for us to make the purchase. I was worried because I was not a technical person, yet I was project managing a technical project full of technical people.

I didn't understand databases or SQL or Java; I didn't even know how a phone worked yet, and I was working for a telecom company! How could I possibly manage a project in this context with so little domain or technical knowledge?!

I was bluffing as best I could, but I thought that one day they would realise I didn't know what I was talking about.

What I didn't realise at the time was that I didn't need to know that stuff because the people that mattered did. In fact, I believe that if I had known that stuff, then I would have been much less successful in my job.

You see, the development team knew about databases and Java and SQL, and the customer knew how phones worked. If I wanted to run the project, I mean really micromanage it, then I would have needed to know all that stuff. But that wasn't my goal.

My goal was to enable the people around me to be able to do what they needed to do, to apply their knowledge, intelligence and experience to making the project and product work. Being an impostor actually helped me avoid being a micromanager.

What I needed to know and learn was how to enable those people. And then I needed to learn to be comfortable with being an impostor.

“Impostor syndrome” is an actual phenomenon – yes, it is widespread enough to have a name – and you may be suffering from Impostor syndrome if you believe:

  • You are a fraud, that you are faking it and that one day soon, you will be "found out"
  • That everyone else knows more than you do
  • The faith that others have in your ability is misplaced
  • That you aren't as good as they seem to believe you are
  • That your successes are largely down to luck, being in the right place at the right time or because of other people

Ever felt like that? It's completely normal. In fact, it would be abnormal if you haven't felt like that because it is believed that up to 70 percent of people have. This certainly matches my personal empirical evidence.

ScrumMasters are perhaps more prone to feelings of Impostor syndrome than anyone else in an agile team or organisation. This is partly because of the lack of authority inherent in the role. They have no power, and so often find themselves doubting themselves and their position.

Their role is also quite loosely defined in terms of their responsibilities and that increases the lack of clarity and confidence that ScrumMasters can have.

Impostor syndrome, like all of the traits that come up in my coaching practice, is not a bad thing. People with Impostor syndrome are generally quite humble, reflective and diligent.

They are constantly trying hard to prove themselves worthy (to themselves and others) and rarely settle for mediocrity because of their anxiety about being found out. As a result, people with a high degree of Impostor syndrome are often high achievers.

It's not therefore a trait to try and get rid of altogether, but rather, it's important to bring it into balance. Harness the positive aspects while trying to mitigate the anxiety and stress that can come from this trait when overdone.

The first step in bringing Impostor syndrome into balance is normalisation – accepting that this is common. Then, consciously appreciating your strengths and bringing others down from the often-overinflated pedestal that you have put them on, because in all likelihood, they are “faking it” just as much as you are!

Bringing this trait into balance for yourself in your role as ScrumMaster may also help you coach others on their Impostor syndrome as well.

There are some great techniques for dealing with this and other traits that can trap us in my new book, “The Coach's Casebook” available now from Amazon here.

SPaMCAST 342 – Gorman, Gottesdiener, Discover to Deliver Revisited

 www.spamcast.net

http://www.spamcast.net

Listen Now

Subscribe on iTunes

Software Process and Measurement Cast 342 features our interview with Ellen Gottesdiener and Mary Gorman.  We discussed their great book, Discover to Deliver: Agile Product Planning and Analysis, requirements and Agile.  Ellen and Mary provided penetrating insight into how to work with requirements in an Agile environment, from discovery to delivery and beyond.

This is the second time Ellen, Mary and I talked Agile requirements.  After listening to this interview turn back the hands of time and listen to SPaMCAST 200.

Ellen Gottesdiener is an internationally recognized leader in the convergence of agile + requirements + product management + project management. She is founder and principal of EBG Consulting, which helps organizations adapt how they collaborate to improve business outcomes.

Ellen’s passion is helping people use modern product requirements practices to build valued products and great teams. She provides coaching, training, and facilitates discovery and planning workshops across diverse industries. Ellen is a world-renowned writer, speaker, and presenter. Her most recent book, co-authored with Mary Gorman, is Discover to Deliver: Agile Product Planning and Analysis. Ellen is author of two other acclaimed books: Requirements by Collaboration and The Software Requirements Memory Jogger.

Here’s where you digitally connect with Ellen: Blog | Twitter | Newsletter | LinkedIn

Mary Gorman, a leader in business analysis and requirements, is Vice President of Quality & Delivery at EBG Consulting. Mary coaches product teams, facilitates discovery workshops, and trains stakeholders in collaborative practices essential for defining high-value products. She speaks and writes for the agile, business analysis, and project management communities. Mary is co-author with Ellen Gottesdiener of Discover to Deliver: Agile Product Planning and Analysis.   

A Certified Business Analysis Professional™, Mary helped develop the IIBA®’s A Guide to the Business Analysis Body of Knowledge® and certification exam. She also served on the task force that created the PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline. You can reach Mary via: Twitter | LinkedIn

Call to action!

Reviews of the podcast help to attract new listeners.  Can you write a review of the Software Process and Measurement Cast and post it on the podcatcher of your choice?  Whether you listen on ITunes or any other podcatcher, a review will help to grow the podcast!  Thank you in advance!

Re-Read Saturday News

The Re-Read Saturday focus on Eliyahu M. Goldratt and Jeff Cox’s The Goal: A Process of Ongoing Improvement began on February 21nd. The Goal has been hugely influential because it introduced the Theory of Constraints, which is central to lean thinking. The book is written as a business novel. Visit the Software Process and Measurement Blog and catch up on the re-read.

Note: If you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast.

Dead Tree Version or Kindle Version 

Next up on Re-Read Saturday: The Mythical Man-Month

Get a copy now and start reading!

Upcoming Events

2015 PROFESSIONAL DEVELOPMENT & TRAINING WORKSHOP
June 9 – 12
San Diego, California
http://www.iceaaonline.com/2519-2/
I will be speaking on June 10.  My presnetaiton is titled “Agile Estimation Using Functional Metrics.”

Let me know if you are attending!

Also upcoming conferences I will be involved in include and SQTM in September, BIFPUG in November. More on these great conferences next week.

Next SPaMCast

The next Software Process and Measurement Cast will feature our essay on Commitment, Part 2. Is commitment anti-Agile?  We think not!  Commitment is a core behavior for effective Agile!

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.


Categories: Process Management

SPaMCAST 342 – Gorman, Gottesdiener, Discover to Deliver Revisited

Software Process and Measurement Cast - Sun, 05/17/2015 - 22:00

Software Process and Measurement Cast 342 features our interview with Ellen Gottesdiener and Mary Gorman.  We discussed their great book, Discover to Deliver: Agile Product Planning and Analysis, requirements and Agile.  Ellen and Mary provided penetrating insight into how to work with requirements in an Agile environment, from discovery to delivery and beyond.

This is the second time Ellen, Mary and I talked Agile requirements.  After listening to this interview turn back the hands of time and listen to SPaMCAST 200.

Ellen Gottesdiener is an internationally recognized leader in the convergence of agile + requirements + product management + project management. She is founder and principal of EBG Consulting, which helps organizations adapt how they collaborate to improve business outcomes.

Ellen’s passion is helping people use modern product requirements practices to build valued products and great teams. She provides coaching, training, and facilitates discovery and planning workshops across diverse industries. Ellen is a world-renowned writer, speaker, and presenter. Her most recent book, co-authored with Mary Gorman, is Discover to Deliver: Agile Product Planning and Analysis. Ellen is author of two other acclaimed books: Requirements by Collaboration and The Software Requirements Memory Jogger.

Here’s where you digitally connect with Ellen: Blog | Twitter | Newsletter | LinkedIn

Mary Gorman, a leader in business analysis and requirements, is Vice President of Quality & Delivery at EBG Consulting. Mary coaches product teams, facilitates discovery workshops, and trains stakeholders in collaborative practices essential for defining high-value products. She speaks and writes for the agile, business analysis, and project management communities. Mary is co-author with Ellen Gottesdiener of Discover to Deliver: Agile Product Planning and Analysis.   

A Certified Business Analysis Professional™, Mary helped develop the IIBA®’s A Guide to the Business Analysis Body of Knowledge® and certification exam. She also served on the task force that created the PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline. You can reach Mary via: Twitter | LinkedIn

Call to action!

Reviews of the podcast help to attract new listeners.  Can you write a review of the Software Process and Measurement Cast and post it on the podcatcher of your choice?  Whether you listen on ITunes or any other podcatcher, a review will help to grow the podcast!  Thank you in advance!

Re-Read Saturday News

The Re-Read Saturday focus on Eliyahu M. Goldratt and Jeff Cox’s The Goal: A Process of Ongoing Improvement began on February 21nd. The Goal has been hugely influential because it introduced the Theory of Constraints, which is central to lean thinking. The book is written as a business novel. Visit the Software Process and Measurement Blog and catch up on the re-read.

Note: If you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast.

Dead Tree Version or Kindle Version 

Next up on Re-Read Saturday: The Mythical Man-Month

Get a copy now and start reading!

Upcoming Events

2015 PROFESSIONAL DEVELOPMENT & TRAINING WORKSHOP
June 9 – 12
San Diego, California
http://www.iceaaonline.com/2519-2/
I will be speaking on June 10.  My presnetaiton is titled “Agile Estimation Using Functional Metrics.”

Let me know if you are attending!

Also upcoming conferences I will be involved in include and SQTM in September, BIFPUG in November. More on these great conferences next week.

Next SPaMCast

The next Software Process and Measurement Cast will feature our essay on Commitment, Part 2. Is commitment anti-Agile?  We think not!  Commitment is a core behavior for effective Agile!

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

Categories: Process Management

Re-Read Saturday: The Goal: A Process of Ongoing Improvement. Part 13

IMG_1249

This week I attended and spoke at the CMMI Global Congress. It was a great conference, and as with most conferences, the conversations in the hallways were as interesting as the presentations (including mine). I had a lot conversations about lean, Agile and scaling Agile, and while the attendees as a whole saw the value, there are still a few that view Agile and lean concepts with derision. These conversations, in conjunction with today’s re-read segment of The Goal, led me to consider whether much of the underlying resistance was being generated by fear; in particular the fear of discovering that what you know is no longer relevant. People facing that fear generally react in one of two ways: reinvention or rejection. In today’s segment Hilton Smyth chooses one of those options. . .

Part 1       Part 2       Part 3      Part 4      Part 5      Part 6      Part 7      Part 8    Part 9   Part 10   Part 11 Part 12

Chapter 31 Alex appears for the plant review, which is being chaired not by Bill Peach (Alex’s boss) but rather Hilton Smyth. Hilton is the assistant division controller. When Alex suggests that they wait for Bill Peach, Hilton indicates that he will not be coming and that his (Hilton’s) report will tip the scales on whether the plant stays open or not. The early exchanges clearly establish that Hilton does not buy into the turn around that Alex and his team have engineered. Alex reiterates the three core findings that have driven the turn around.

  1. Instead of balancing capacity with demand, they are focused on maintaining and improving the flow through the plant.
  2. For resources that are not bottlenecks, the level of activity from which the system is able to profit is not determined by individual capacity, but rather by some other constraint.
  3. Utilization and activation are not the same.

Hilton believes that Alex’s deviations from the tried and true formulas for batch size, capacity utilization and per unit costing are hiding problems that will cripple the plant in the future. Those tried and true formulas are central to Hilton’s perception of his own relevance, and he can’t see that with both profits and plant throughput up and inventory down that the plant is now on very solid footing. The report to Peach will be bad.

After the meeting, Alex decides to confront Peach. Peach listens as Alex tells him that Smyth would not listen to reason. Peach summons Jons (head of sales), Ethan Frost (division controller and Smyth’s boss) and Smyth. When they are assembled, Peach announces that Jons, Frost and himself have been promoted, and that Alex will also be promoted to head the division. While unstated in the book the inference is that recent profitability and the new orders from Bucky Burnside have made quite the stir at corporate. (In my head I could hear Smyth blustering, as much of his previous knowledge and experience became less relevant).

The chapter ends with Alex reaching out to Jonah to ask for help running the division. What he receives is a congratulation and advice to learn to trust his own judgement rather than to needing outside support.

Chapter 32 uses Alex’s and Julie’s celebration dinner as a backdrop for a discussion about the promotion as part of a journey and Johan’s method of coaching. Johan didn’t just provide answers to the questions Alex posed, but rather pushed Alex  in the right direction and made him and his team work for the answers, much like the Socratic method of generating critical thinking based on asking and answering questions.  This journey helped Alex generate ownership in new concepts that flew in the face of what he and his team previously thought to be true. The struggle to generate answers gave Alex and his team the courage to implement their new ideas. It should be noted that the feedback that their early successes generated also helped generate the courage to try further experiments (this dovetails nicely to the ideas in Kotter’s Leading Change – an earlier re-read).

Remember that the summary of previous entries in the re-read of The Goal have been shifted to a new page (click here).   Also, if you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast. Dead Tree Version or Kindle Version


Categories: Process Management

Agile goes beyond Epic Levels

Xebia Blog - Fri, 05/15/2015 - 17:10

IMG_5514A snapshot from my personal backlog last week:

  • The Agile transformation at ING was frontpage news in the Netherlands. This made us even more realize how epic this transformation and assignment actually is.
  • The Agile-built hydrogen race car from the TU Delft set an official track record on the Nurburgring. We're proud on our guys in Delft!
  • Hanging out with Boeings’ Agile champs at their facilities in Seattle exchanging knowledge. Impressive and extremely fruitful!
  • Coaching the State of Washington on their ground breaking Agile initiatives together with my friend and fellow consultant from ScrumInc, Joe Justice.

One thing became clear for me after a week like this: Something Agile is cookin’.  And it’s BIG!

In this blog I will be explaining why and how Agile will develop in the near future.

Introduction; what’s happening?

Human kind is currently facing the biggest era change since the 19th Century. Our industries, education, technologies and society are simply not compliant anymore with today’s and tomorrows needs.  Some systems like healthcare and the economy are that broken they actually should be to be reinvented again. Everything has just become too vulnerable and complex. Just Quantitative-easing“lubricating the engine” like quantitive easing the economy, are no sustainable solutions anymore. Like Russell Ackoff already said, you can only fix a system as a whole not only by separate parts.

This reinvention will only succeed when we are able to learn and adjust our systems very rapidly.  Agile, Lean and a different way of organizing our selfs, can make this reality.  Lean will provide us with the right tools to do exactly what’s needed, nothing more, nothing less.  But applying Lean for only efficiency purposes will not bring the innovations and creativity we need.  We also need an additional catalyst and engine: Agile. It will provide us with the right mindset and tools to innovate, inspect and adapt very fast.  And finally, we must reorganize ourself more on cooperation not on directive command and control. This was useful in the industrial revolution, not in our modern complex times.

Agile’s for everything

Unlike most people think, Agile is not only a software development tool. You can apply it to almost everything. slider_Forze_VI_ValkenburgFor example, as Xebia consultants we've successfully coached Agile and Lean non-IT initiatives in Marketing, Innovation, Education, Automotive, Aviation and non-Profit organizations. It just simply works! And how. A productivity increase of 500% is no exception. But above all, team members and customers are much happier.

Agile's for everybody

At this moment, a lot of people are still unconsciously addicted to their patterns and unaware about the unlimited possibilities out there.  It’s like having a walk in the forrest.  You can bring your own lunch like you always do, but there are some delicious fruits out there for free!  Technology like 3D printing offer unlimited possibilities straight on your desk, where only a few years a go, you needed a complicated, million dollar machine for this. The same goes for Agile. It’s open source and out there waiting for you. It will also help you getting more out of all these new awesome developments!

The maturity of Agile explained

Until recently, most agile initiatives emerged bottom up, but stalled on a misfit between Agile and (conventional) organizations.  Loads of software was produced, but could not be brought to production, simply because the whole development chain was not Agile yet. Tools like TDD and Continuous Integration improved the situation significantly, but dependencies were still not managed properly most of the time.

Screen Shot 2015-05-13 at 7.53.15 PM

The last couple of years, some good scaled agile frameworks like LeSS and SAFe emerged. Managing the dependencies better, but not directly encouraging the Agile Mindset and motivation of people.  In parallel, departments like HR, Control and Finance were struggling with Agile. There was a scaled agile framework implemented, but the hierarchical organization structure was not adjusted creating a gap between fast moving Agile teams and departments still hindered by non-Agile procedures, proceses and systems.

Therefor, we see conventional organizations moving towards a more Agile, community based model like Spotify, Google or Zappos.  ING is now transforming towards to a similar organization model.

Predictions for the near future

My expectation is that we will see Agile transformations continue on a much wider scale.  For example, people developing their own products in an agile fashion while using 3D printing.  Governments will use Agile and Holacracy for solving issues like the reshaping the economic system together with society. Or like I have observed last week, the State of Washington government using these techniques successfully in solving the challenges they're facing.

For me, it currently feels like the early Nineties again when the Internet emerged.  In that time I explained to many people the Internet would be like electricity for them in the near future.  Most people laughed and stated it was just a new way of communication.  The same applies now for the Agile Mindset.   It's not just a hype or a corporate tool. It will reshape the world as we know it today.