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

Story Telling Techniques: The Premortem

Identify the risks before you start with a premortem.

Storytelling generates the big picture to guide a project or to help people frame their thoughts. A story can provide a deeper and more nuanced connection with information than most lists of PowerPoint bullets or a structured requirements documents. Storytelling can be used as a risk management tool.  Premortems are a useful tool for helping project teams anticipate risks.  Premortems were described in the Harvard Business Review, September 2007 by Gary Klein.  The basic premortem approach can be can be customized with storytelling to increase the power of the technique.

The basic premortem technique is as follows:

Step 1 – Prepare: Gather the project.

Step 2 – Have the team assume the project has utterly failed and then ask the question what caused the failure.

Step 3 – Ask each person to quietly write down all of the reasons they think the failure occurred in three minutes.

Step 4 – Using a round robin approach have each person shares one item on their list at a time with a facilitator recording the reasons on a whiteboard or flipchart.  Continue until all items are shared and recorded.

**The first four steps help defeat groupthink.

Step 5 – Identify the top 3 -5 items on the list and create user stories identifying the risks.  These high priority risks will be added to the backlog and revisited during grooming.  Common issues should be added to the team’s definition of done.

Step 6 – Periodically review the overall list with the team to determine whether any of the risks not added in step 5 have become more urgent. 

A more powerful twist to the standard process replaces steps 2 – 4 with a storytelling technique.

  • Break the team into pairs.
  • Provide the participants with an overview of the storytelling process, storytelling formats and the goal of the session.
  • Provide the participants with the premise that the project has failed and ask them to tell the story of how that point was reached.
  • Use probing questions to help the teams progress in generating the story. The sub-teams should be cross-functional. Time box this portion of the session to 15 minutes.
  • Have each team debrief the group with their stories.
  • Have the full team identify the issues that shaped the stories, these are potential risks.  The most critical risks should be added to the backlog (or if common to the definition of done).

When using the premortem storytelling technique there are a few important rules (many of these are useful for all types of storytelling sessions).

  1. Minimize interruptions, close laptops and have people put their phones away (consider collecting people’s phones).
  2. Set aside approximately two hours for generating the stories and to discuss the results.
  3. The whole project team and important stakeholders should be present or you will risk blind spots.
  4. If some members are not present video conferencing is important to create personal connections.
  5. A facilitator is important to making the process effective.  The facilitator should not be a critical team member or stakeholder. 
  6. The facilitator must ensure that the stories from the session are captured and the top 3 – 5 (more or less based on team’s discretion) are added to the product backlog. 

The premortem is an excellent tool to increase the team’s involvement and understanding of the understanding of risks.  Adding storytelling to the technique increases the richness of the experience over common brainstorming and listing techniques.  The results of a storytelling premortem will not only identify risks but provide the context of how the team members think the risks will emerge and turn into issues.  

 


Categories: Process Management

Better User Stories: 24 Hours Until Doors Close

Mike Cohn's Blog - Tue, 03/28/2017 - 17:00

This blog post refers to a four-part series of videos on overcoming challenges with user stories. Topics covered are conducting story-writing workshops with story maps, splitting stories, and achieving the right level of detail in user stories.

To be notified when you the videos are again available, sign up below:

Notify Me!

Just a quick post this week to let you know that we will be closing registration to Better User Stories tomorrow at 6 P.M. Pacific, 9 P.M. Eastern.

We still have spaces for the Expert and Professional Levels, but Work With Mike is now completely sold out.

Click here to register before the deadline

Just a quick reminder of what people are saying about the course:

I could squeeze videos in between meeting packed days

“I loved the acronyms used to test story quality and that the modules were broken up into small enough segments that I could squeeze videos in between meeting packed days… I really enjoyed the worksheets that forced me to use my own backlog as practice to cement the concepts in my brain. It's way too easy to go through an online course and not really retain information that is useful later but that's what made it real for me.” - Sarah Fraser

Immediately able to apply what I learned

“I've used user stories for many years. I wasn't sure if this course was really going to teach me something new… I thought if anyone is going to be able to teach me more about user stories it will be Mike Cohn… The Q&A calls with the training were great. I think this is a big differentiator to other online trainings I've done. I was immediately able to apply what I learned in this course to support teams get their backlog set up as they begin delivering using the scrum framework. - Amber Burke

If you’re on the fence, jump in…

“It has already influenced and changed how I deliver story writing workshops. There is a lot of valuable information. It is split up into logical and digestible segments. For anyone willing to put in the time that needs to understand how to write better stories; you will find value here. If you're on the fence, jump in...you won't regret it.” - Max Lamers

You still have (some) time to access the free mini-course

When we close registration to the full Better User Stories course, we will also be taking down the free video training. If you’ve not yet seen those, you still have time to register and watch them before tomorrow’s deadline.

Click here to access the free mini-course

I don’t know when we’ll be opening doors again to the full, advanced course, so if you and your team want to sharpen your user stories skills, this is a great time to join.

Any last minute questions about the course? Let me know in the comments below.

Agile & Software Testing in Methods & Tools Q1 2017 articles

From the Editor of Methods & Tools - Tue, 03/28/2017 - 15:35
Here is a list of the articles published during the first quarter of 2017 on the Methods & Tools website. This quarter Methods & Tools has published articles discussing the management debt issue in Agile transformation, Agile forecasting and testing microservices. We also published two articles presenting open source software testing tools: CasperJS and Nitrate. […]

SPaMCAST 435 – Allan Kelly, #NoProjects, Value

SPaMCAST Logo

http://www.spamcast.net

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

The Software Process and Measurement Cast 435 features our interview with Allan Kelly.  Our discussion touched on the concepts behind #NoProjects.  Allan describes how the concept of a project leads to a number of unintended consequences.  Those consequences aren’t pretty.

Allan makes digital development teams more effective and improves delivery with continuous agile approaches to reduce delay and risk while increasing value delivered. He helps teams and smaller companies – including start-ups and scale-ups – with advice, coaching and training. Managers, product, and technical staff are all involved in his improvements. He is the originator of Retrospective Dialogue Sheets and Value Poker, the author of four books, including “Xanpan – team-centric Agile Software Development” and “Business Patterns for Software Developers”. On Twitter he is @allankellynet.

Re-Read Saturday News

This week we tackle Chapter 8 of Carol Dweck’s Mindset: The New Psychology of Success (buy your copy and read along).  Chapter 8, titled “Changing Mindsets.” The whole concept of mindsets would be an interesting footnote if we did not believe they could change. Chapter 8 drives home the point that has been made multiple times in the book, that mindsets are malleable with self-awareness and a lot of effort. The question of whether all people want to be that self-aware will be addressed next week as we wrap up our re-read.

We are quickly closing in on the end of our re-read of Mindset.  I anticipate one more week.   The next book in the series will be Holacracy (Buy a copy today). After my recent interview with Jeff Dalton on Software Process and Measurement Cast 433, I realized that I had only read extracts from Holacracy by Brian J. Robertson, therefore we will read (first time for me) the whole book together.

Every week we discuss a chapter then consider the implications of what we have “read” from the point of view of both pursuing an organizational transformation and also using the material when coaching teams.  

Remember to buy a copy of Carol Dweck’s Mindset and start the re-read from the beginning!

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

Next SPaMCAST

The next Software Process and Measurement Cast will feature our essay on incremental change approaches.  We will also have columns from Jeremy Berriault. Jeremy blogs at https://jberria.wordpress.com/  and Jon M Quigley who brings his column, the Alpha and Omega of Product Development, to the Cast. One of the places you can find Jon is at Value Transformation LLC.

 


Categories: Process Management

SPaMCAST 435 - Allan Kelly, #NoProjects, Value

Software Process and Measurement Cast - Sun, 03/26/2017 - 22:00

The Software Process and Measurement Cast 435 features our interview with Allan Kelly.  Our discussion touched on the concepts behind #NoProjects.  Allan describes how the concept of a project leads to a number of unintended consequences.  Those consequences aren’t pretty.

Allan makes digital development teams more effective and improves delivery with continuous agile approaches to reduce delay and risk while increasing value delivered. He helps teams and smaller companies - including start-ups and scale-ups - with advice, coaching and training. Managers, product and technical staff are all involved in his improvements. He is the originator of Retrospective Dialogue Sheets and Value Poker, the author of four books, including "Xanpan - team-centric Agile Software Development" and "Business Patterns for Software Developers". On Twitter he is @allankellynet.

Re-Read Saturday News

This week we tackle Chapter 8 of Carol Dweck’s Mindset: The New Psychology of Success (buy your copy and read along).  Chapter 8, titled “Changing Mindsets.” The whole concept of mindsets would be an interesting footnote if we did not believe they could change. Chapter 8 drives home the point that has been made multiple times in the book, that mindsets are malleable with self-awareness and a lot of effort. The question of whether all people want to be that self-aware will be addressed next week as we wrap up our re-read.

We are quickly closing in on the end of our re-read of Mindset.  I anticipate one more week.   The next book in the series will be Holacracy (Buy a copy today). After my recent interview with Jeff Dalton on Software Process and Measurement Cast 433, I realized that I had only read extracts from Holacracy by Brian J. Robertson, therefore we will read (first time for me) the whole book together.

Every week we discuss a chapter then consider the implications of what we have “read” from the point of view of both someone pursuing an organizational transformation and using the material when coaching teams.  

Remember to buy a copy of Carol Dweck’s Mindset and start the re-read from the beginning!

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

Next SPaMCAST

The next Software Process and Measurement Cast will feature our essay on incremental change approaches.  We will also have columns from Jeremy Berriault. Jeremy blogs at https://jberria.wordpress.com/  and Jon M Quigley who brings his column, the Alpha and Omega of Product Development, to the Cast. One of the places you can find Jon is at Value Transformation LLC.

 

Categories: Process Management

Mindset: The New Psychology of Success: Re-Read Week 9, Chapter 8, Changing Mindsets: A Workshop

Mindset Book Cover

Next week we will complete our re-read of Mindset with a round-up and some thoughts on using the concepts in this book in a wholesale manner.  The next book in the series will be Holacracy.  Buy a copy today and read along!  I have had a couple of questions about why did not do a poll for this re-read.  As I noted last week, after my recent interview with Jeff Dalton on Software Process and Measurement Cast 433, I realized that I had only read extracts from Holacracy by Brian J. Robertson.  I think many of us are looking for an organizational paradigm for Agile organizations.  Hierarchies and matrix organizations have clear and immediate drawbacks.  Holacracy might be one tool to address this problem, which why we will read this book.

One more thing — If you are going to be at QAI Quest 2017 April 3 – 7, please come hear me speak and track me down for a coffee or adult beverage and we can talk shop! 

Chapter 8: Changing Mindsets

The whole concept of mindsets would be an interesting footnote if we did not believe they could change. Chapter 8 drives home the point that has been made multiple times in the book, that mindsets are malleable with self-awareness and a lot of effort. The question of whether all people want to be that self-aware will be addressed next week as we wrap up our re-read.

Dr. Dweck opens the chapter by using the metaphor of surgery to illustrate why change is difficult. For example, if you have a wart a doctor will freeze it or cut it off.  It is gone.  Old behaviors don’t lend themselves to surgical removal. They are always still lurking in the background and can come back.  They are never excised.  If we wanted a medical metaphor, behaviors are more like the virus that causes shingles which enters the body as chicken pox, runs its course and then lingers forever after to potentially reemerge over and over (PS – get the vaccination).  When I was young, I smoked.  I don’t know how many times I quit only to relapse.  Every time I relapsed I knew shouldn’t buy that pack or bum a smoke but did it anyway.  If I had branded myself as weak I would have never I climbed back on the wagon and learned from the triggering event. Dweck points out that our mind is always keeping track and interpreting, keeping a running account, of our actions based on our mindset. That accounting process can be the difference between see not meeting a goal such smoking cessation as a learning even or being branded a failure.  Our mindsets generate internal dialogs that can empower or “unpower” (I made up this word).  A growth mindset generates a different internal dialog and a fixed mindsets fill in the internal dialog.   A growth mindset looks for the learning opportunity

Mindsets are not fixed.  In studies presented in Chapter 8, just learning that you have or lean toward a fixed mindset can cause change.  The act of learning provides knowledge that can be helpful to confront the self-destructive behaviors at the heart of a fixed mindset.  Knowing is not always a sufficient mechanism for change.

Chapter 8 provides insights into several academic and commercial approaches Dweck has used to affect change.  The common thread in all of the effective approaches outlined in the chapter is a belief that you are in charge of your mind and your mind can grow (metaphorically).  Change however is difficult.  In order to change an individual has to be able to give up their current self-image and replace the self-image.  Replacing your self-image is frightening.  You have to give up something known and replace it with something else that might sound better but that you have no experience with.  

The process of changing from a fixed to a growth mindset begins with making a “vivid, concrete, growth-oriented plan” that includes specific”when, where, and how” components.  Execution needs to be coupled with feedback, support and mentoring.  None of the good techniques and examples provided will suffer from willpower and the ability to learn from feedback.

Using Mindsets:

Organizational Transformation:  Mindsets provide a tool for considering how organization transformation will be perceived and the predicting the unintended consequences of change. For example, if an organization was trying to shift from a risk-adverse culture to a more innovative culture messaging would tend to focus on growth opportunities, failing fast and learning.  To people within the organization with growth mindsets, these concepts would make sense and be easily absorbed (assuming the organization’s actions supported the words for the most part).  However, those with a fixed mindset (potentially some key players and top individual performers) would first need to recognize that their behavior has to change.  The organization would need to actively provide growth plans to support their transition.  Using mindsets in organizational transformation plans is using for change management, messaging and risk planning. At an organizational level, using mindsets in planning is an important though exercise that can guide other activities including team level coaching.

Team Coaching: The sentence, “a vivid, concrete, growth-oriented plan” reflects one of the more important tactical realities that must be remembered when using mindsets at a team or personal level.  Teams and organizations don’t change, it is all about the people.  Individual people change which then influence the team or organization.  Coaches need should begin any team coaching activities by targeting leaders/influencers.  Think of the game Jenga, game pieces are removed until the key piece is exposed and when removed the tower falls.  Transforming a team is much akin to anti-Jenga.  The goal is to find the critical piece and help them to change. Change requires self-realization, a plan, effort and support.    

Previous Entries of the re-read of Mindset:

Basics and Introduction

Chapter 1: Mindsets

Chapter 2: Inside the Mindsets

Chapter 3: The Truth About Ability and Accomplishment

Chapter 4: Sports: The Mindset of a Champion

Chapter 5: Business: Mindset and Leadership

Chapter 6: Relationships: Mindsets in Love (or Not)

Chapter 7: Parents, Teachers, Coaches: Where Do Mindsets Come From?

 


Categories: Process Management

Monitor Your Mesos Cluster with StackState

Xebia Blog - Fri, 03/24/2017 - 09:28

This post is part 2 in a 4-part series about Container Monitoring. Post 1 dives into some of the new challenges containers and microservices create and the information you should focus on. This article describes how to monitor your Mesos cluster. Apache Mesos is a distributed systems kernel at the heart of the Mesosphere DC/OS and is designed […]

The post Monitor Your Mesos Cluster with StackState appeared first on Xebia Blog.

Change Fatigue, Tunnel Vision, and Watts Humphrey

Traffic in India

I recently spent a week Mumbai. While stuck in traffic during a tour of some of the incredible sights, our guide stated that in Mumbai there were three certainties, death, taxes and traffic. With the sound of auto and truck horns ringing in my ear, that statement rang true.  On reflection, I would add change to the list of certainties, whether in Mumbai or as a general attribute of all human endeavors.  Software development and maintenance are no different. Over the past few weeks, this blog has extolled and then pilloried the virtues of both big bang and incremental change approaches (and by inference everything in-between). In the end, there is no perfect approach that fits all scenarios. How can we decide which end of the change approach spectrum will work in any given scenario?  The answer is not as straightforward as a checklist or decision tree, rather three interrelated concepts must be weighed when deciding on a change approach. The three are the organization’s propensity to fall prey to change fatigue, the possibility of tunnel vision and the tolerance for dealing with Watts Humphrey’s requirements uncertainty principle.

Change fatigue occurs when the combination of a high pace of change and a negative perception the value or success of change, collide. One of the mantras of the software development industry is that the pace of technological change is fast and getting faster. One form of evidence of the pace of change is that nearly every person has to reinvent themselves at least once, and often many times.  This constant change churn sets the stage for the propensity for change fatigue to pop up at a moment’s notice if they feel they are working toward change don’t they see as successful or valuable (either to themselves directly or to their organization). In organizations with this smoldering change fatigue lurking below the surface, slowing down the rate of change by consolidating smaller (more incremental) changes can be a useful strategy.

Tunnel vision is a singular focus on one thing to the absolute exclusion of everything else. In medical terms, tunnel vision is not considered a positive.  In the business and IT environment, the medical definition is often confused with the more sought after the concept of focus. While it is easy to see a relationship, they are not the same. When focus crosses the line and causes an organization to neglect or ignore other important priorities, focus becomes as destructive tunnel vision. One of the attributes of a big bang change program is that it is often too big to fail.  When an organization develops tunnel vision and begins to ignore feedback, they have entered the danger zone. An organization’s culture can be a powerful tool to predict whether tunnel vision is a major risk.  Organizations that have an extreme fear of failure or pride themselves for persevering at all odds are apt to fall prey to tunnel vision.  Early in my career, I worked for a firm that proudly stated that if any of their projects got into trouble they would “darken the skies with engineers.” This almost always busted the budget and was career limiting. The two competing cultural components tended to cause leaders to block out negative feedback.  The culture fostered tunnel vision.  In those cases having a focus had became tunnel vision. The managers and stakeholder put blinders on and ignored feedback until it was too late to correct their course. If an organization is at higher risk for tunnel vision due to its culture, incremental change approaches are a tool to create a mechanism to break the focus and challenge the vision and to generate and interpret feedback.

Watts Humphrey, the founder of the Software Engineering Institute and contributor of some of the most significant thought leadership to the software development over his lifetime, established the principle of requirements uncertainty.  In its very simplest form, the principle can be stated as “they won’t completely know it until they see it.”  The amount of uncertainty establishes how far into the future a project team or organization will comfortably commit to a direction.  The more uncertainty the shorter amount time into the future a team can commitment.  This requirement uncertainty principle screams incrementalism.  As Todd Field suggested, “a short commitment cycle (incrementalism) does not preclude a longer term vision” (watch the tunnel vision).  Several frameworks for scaling Agile build this risk mitigation cycle into their methods.  For example, the Scaled Agile Framework Enterprise (SAFe) is built around a process that recognizes uncertainty. SAFe includes a long-term roadmap for each product.  The roadmap becomes less specific the further it extends into the future reflecting uncertainty. Specific program increments (PI) define what will be delivered over a 90 (ish) day window reflecting more certainty that comes from a short, fixed time horizon. In a further attempt to reduce uncertainty, the PI evolves based on the feedback and results from short sprints or iterations. SAFe represents a hybrid approach that mixes big bang and incremental concepts. The process provides organizations a way to define what they intend to deliver in the future while accepting that real life creates situations that need to be addressed.  The more uncertainty a change program faces the shorter the increment of commitment should be.

The state and culture of the organization or team has or can have a large impact on whether a Big Bang approach or an incremental approach makes sense.  I think the most succinct answer I got when I asked which change approach made the most sense was from Lee Copeland, Talent Scout at TechWell, Lee answered with one word, “depends.”


Categories: Process Management

Doors Now Open to the Better User Stories Advanced Video Training

Mike Cohn's Blog - Wed, 03/22/2017 - 13:05

This blog post refers to a four-part series of videos on overcoming challenges with user stories. Topics covered are conducting story-writing workshops with story maps, splitting stories, and achieving the right level of detail in user stories.

To be notified when you the videos are again available, sign up below:

Notify Me!

This past week we’ve given away free online training and a number of resources to help you combat some of the most vexing problems agile teams encounter when writing user stories.

Now it’s time to open the doors to the full course: Better User Stories.

“In my 30 years of IT experience, this class has without question provided the most ‘bang for buck’ of any previous training course I have ever attended. If you or your organization are struggling with user stories, then this class is absolutely a must have. I simply can’t recommend it enough. 5 Stars!!” - Douglas Tooley

If you watched and enjoyed the free videos, you’ll love Better User Stories. It’s much more in-depth, with 9 modules of advanced training, worksheets, lesson transcripts, audio recordings, bonus materials, and quizzes to help cement the learning.

Registration for Better User Stories will only be open for one week

Click here to read more about the course and reserve your seat.

Because of the intense level of interest in this course, we’re expecting a large numbers of people to sign-up. That’s why we’re only opening the doors for one week, so that we have the time and resources to get everyone settled.

If demand is even higher than we expect, we may close the doors early, so if you already know you’re interested, the next step is to:

Choose one of 3 levels of access. Which is right for you?

I know when it comes to training, everyone has different needs, objectives, learning preferences and budgets.

That’s why you can choose from 3 levels of access when you register:

  • Professional - Get the full course with lifetime access to all materials and any future upgrades
  • Expert Access - Acquire the full course and become part of the Better User Stories online community, where you can discuss ideas, share tips and submit questions to live Q+A calls with Mike
  • Work With Mike - Secure all of the above, plus private, 1:1 time with Mike to work through any specific issues or challenges.

Click here to choose the best level for your situation

What people are already saying

We recently finished a beta launch where a number of agilists worked through all 9 modules, providing feedback along the way. This let us tweak, polish and finish the course to make it even more practical and valuable.

Here’s what people had to say:

Anne Aaroe

Thank you for an amazing course. Better User Stories is by far the best course I have had since I started my agile journey back in 2008.

Anne Aaroe

Packed full of humor, stories, and exercises the course is easy to take at one’s own leisure. Mike Cohn has a way of covering complex topics such as splitting user stories with easy to understand acronyms, charts and reinforces these concepts with quizzes and homework that really bring the learning objectives to life. So, whether you’re practicing scrum or just looking to learn more about user stories this course will provide you the roadmap needed to improve at any experience level, at a cost that everyone can appreciate.

Aaron Corcoran

Click here to read a full description of the course, and what you get with each of the 3 levels of access. Questions about the course?

Let me know in the comments below.

Docker container secrets on AWS ECS

Xebia Blog - Wed, 03/22/2017 - 08:42

Almost every application needs some kind of a secret or secrets to do it's work. There are all kind of ways to provide this to the containers but it all comes down to the following five: Save the secrets inside the image Provide the secrets trough ENV variables Provide the secrets trough volume mounts Use a secrets […]

The post Docker container secrets on AWS ECS appeared first on Xebia Blog.

Three Problems That Let The Air Out of Effective Incremental Change

partially inflated balloons

Where did the air go?


The overwhelming choice of process improvement specialists is incremental change.  The 21st century has seen an explosion in the use of incremental change methods, not just in process improvement, but in software development and maintenance.  Techniques and frameworks like Scrum, Extreme Programing and Kanban are just a sample of methods that are being used.  The support for incrementalism should not be taken as a carte blanche endorsement.  In order to effectively use incremental change, a practitioner must avoid these three major pitfalls:

  1. Resistance to constant “upheaval” caused by incremental or continuous process improvement.  Constant change can lead to change fatigue.  Change fatigue is  “a general sense of apathy or passive resignation towards organizational changes by individuals or teams.”  In the article titled, Change Fatigue: Taking Its Toll on Your Employees? by Kotter International includes uncredited research claiming that 70% of transformation efforts fail. Whether the exact number is 70%, a large percentage of change programs fail, which reinforces the perception that it is not worth effort.  David Galvin and Jane Cizik of Harvard Business School indicated that to defeat change fatigue all changes need to follow a pattern of recognition and preparation followed by implementation and then consolidation.   The consolidation gives people a chance to recover and recognize success.
  2. Losing focus due to incrementalism. In scenarios in which an incremental change program does not have a strong vision change can wander off track.  Todd Field, senior project manager, stated that “while incremental change makes sense for progress, for the vision, it needs to be Big Bang.” A strong vision makes effective incremental change possible.  Without a strong vision that gets repeated the organization will not have a touchpoint to stay on track when distractions or disappointments occur. A common comment that change practitioners hear is the current “thing” being pursued to make an organization better is just the current fad on the cover of industry magazines, and as soon as the headline changes so will focus in the organization.  This this the other side of the potential problem with the potential for losing focus during Big Bang implementations because time drags on.
  3. Continuous process improvement requires more active scope management. Incremental or continuous process improvement will be made up of many smaller parts.  As feedback is generated and the organization gets into the swing of the change program, the scope can grow. There are many reasons for scope creep ranging from general excitement to it just being difficult to know which change belongs in the program. Regardless of the reason, scope creep can sap the resources set aside for the change program. Kristie Lawrence, organizational quality engineer and IFPUG Board Member, stated: “The trick is to manage the scope of what is being improved.”  

Even if continuous process improvement might be the choice of process improvement specialists, it might not always be the best approach.  As Steven Adams stated, “Continuous process improvement is a less risky route.  But it could be the slower route and may not even allow an organization to get where it wants to go.” Change is a given in all organizations.  What isn’t a given is that the change will happen the way anyone plans it to happen.

 


Categories: Process Management

TDD is not about unit tests

Xebia Blog - Tue, 03/21/2017 - 14:42

-- Dave Farley & Arjan Molenaar On many occasions when we come at a customer, we're told the development team is doing TDD. Often, though, a team is writing unit tests, but it's not doing TDD. This is an important distinction. Unit tests are useful things. Unit testing though says nothing about how to create […]

The post TDD is not about unit tests appeared first on Xebia Blog.

How to Add the Right Amount of Detail to User Stories

Mike Cohn's Blog - Tue, 03/21/2017 - 13:00

This blog post refers to a four-part series of videos on overcoming challenges with user stories. Topics covered are conducting story-writing workshops with story maps, splitting stories, and achieving the right level of detail in user stories.

To be notified when you the videos are again available, sign up below:

Notify Me!

Today’s post introduces the third installment in a free series of training videos all about user stories. Available for a limited time only, you can watch all released videos by signing up to the Better User Stories Mini-Course. Already signed up? Check your inbox for a link to the latest video, or continue reading to find out about today’s lesson.

An extremely common problem with user stories is including the right amount of detail.

If you include too much detail in user stories this makes story writing take longer than it would otherwise. As with so many activities in the business world, we want to guard against spending more time on something than necessary.

Also, spending time adding too much detail leads to slower development as tasks like design, coding, and testing do not start until the details have been added. This delay also means it takes longer for the team and its product owner to get feedback from users and stakeholders.

But adding too little detail can lead to different but equally frustrating problems. Leave out detail and the team may struggle to fully implement a story during a sprint as they instead spend time seeking answers.

With too little detail, there’s also an increased chance the development team will go astray on a story by filling in the gaps with what they think is needed rather than asking for clarification.

There’s danger on both sides.

But, when you discover how much detail to add to your stories, it’s like Goldilocks finding the perfect bowl of porridge. Not too much, not too little, but just right.

But how do you discover how much is the right amount?

You can learn how in a new, 13-minute free video training I’ve just released. It’s part of the Better User Stories Mini-Course. To watch the free video, simply sign up here and you’ll get instant access.

Remember, if you’ve already signed up to the course you don’t need to sign in again, just go to www.betteruserstories.com and video #3 will already be unlocked for you.

Adding the right amount of detail--not too much, not too little--is one of the best ways to improve how your team works with user stories. I’m confident this new video will help.

Mike

P.S. This video is only going to be available for a very short period. I encourage you to watch it now at www.betteruserstories.com.

Software Development Linkopedia March 2017

From the Editor of Methods & Tools - Mon, 03/20/2017 - 14:25
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 sharing information, team conflicts, leadership, meetings, DevOps, test management, refactoring software architecture, pair testing, software design and scaling Agile. Text: How I Share Information with my Team Text: Helping Teams […]

SPaMCAST 434 – Big Bang or Not, Human Side of Flow, Fermi Questions

SPaMCAST Logo

http://www.spamcast.net

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

The Software Process and Measurement Cast 434 features our essay on Change Implementations – To Big Bang or Not To Big Bang? The knee jerk reaction amongst transformation leaders is usually a loud NO! However, the answer is not nearly that cut and dry.  Big Bang approaches to change have a place in bag of tricks every transformation leader has at their fingertips.

The second column this week is from Steve Tendon. Steve Tendon brings another chapter in his Tame The Flow: Hyper-Productive Knowledge-Work Performance, The TameFlow Approach and Its Application to Scrum and Kanban, published by J Ross (buy a copy here) to the cast.  In this installment, we talk about Chapter 16, The (Super)-Human Side of Flow. In Chapter 16 Steve and Wolfram go into detail on in Kotter’s attributes of flow state.  A good discussion and a good read.

Our third column is from the Software Sensei, Kim Pries.  Kim discusses Fermi Problems. Fermi problems or questions are a tool to teach approximation and estimation.  These problems usually can be solved logically as a back-of-the-envelope calculation. The last time we talked about Fermi Problems was when we were re-reading How To Measure Anything (Hubbard).

Re-Read Saturday News

This week we tackle Chapter 7 of Carol Dweck’s Mindset: The New Psychology of Success (buy your copy and read along).  Chapter 7, titled “Parents, Teachers, Coaches: Where Do Mindsets Come From? explores the impact of some of the most intimate and earliest relationships on our mindsets. Understanding how parents, teachers, and coaches affect mindsets helps us learn to lead change.

We are quickly closing in on the end of our re-read of Mindset.  I anticipate two more weeks (Chapter 8 and a round up).  The next book in the series will be Holacracy (Buy a copy today). After my recent interview with Jeff Dalton on Software Process and Measurement Cast 433, I realized that I had only read extracts from Holacracy by Brian J. Robertson, therefore we will read (first time for me) the whole book together.

Every week we discuss a chapter then consider the implications of what we have “read” from the point of view of both someone pursuing an organizational transformation and using the material when coaching teams.  

Remember to buy a copy of Carol Dweck’s Mindset and read along!

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

Next SPaMCAST

The next Software Process and Measurement Cast will feature our interview with Allan Kelly.  Our discussion touched on the concepts behind #NoProject.  Allan describes how the concept of projects leads to a number of unintended consequences.  Those consequences aren’t pretty.

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, for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.

 


Categories: Process Management

SPaMCAST 434 - Big Bang or Not, Human Side of Flow, Fermi Questions

Software Process and Measurement Cast - Sun, 03/19/2017 - 22:00

The Software Process and Measurement Cast 434 features our essay on Change Implementations - To Big Bang or Not To Big Bang? The knee jerk reaction amongst transformation leaders is usually a loud NO! However, the answer is not nearly that cut and dry.  Big Bang approaches to change have a place in bag of tricks every transformation leader has at their fingertips.

The second column this week is from Steve Tendon. Steve Tendon brings another chapter in his Tame The Flow: Hyper-Productive Knowledge-Work Performance, The TameFlow Approach and Its Application to Scrum and Kanban, published by J Ross (buy a copy here) to the cast.  In this installment, we talk about Chapter 16, The (Super)-Human Side of Flow. In Chapter 16 Steve and Wolfram go into detail on in Kotter’s attributes of flow state.  A good discussion and a good read.

Our third column is from the Software Sensei, Kim Pries.  Kim discusses Fermi Problems. Fermi problems or questions are a tool to teach approximation and estimation.  These problems usually can be solved logically as a back-of-the-envelope calculation. The last time we talked about Fermi Problems was when we were re-reading How To Measure Anything (Hubbard).

Re-Read Saturday News

This week we tackle Chapter 7 of Carol Dweck’s Mindset: The New Psychology of Success (buy your copy and read along).  Chapter 7, titled “Parents, Teachers, Coaches: Where Do Mindsets Come From? explores the impact of some of the most intimate and earliest relationships on our mindsets. Understanding how parents, teachers, and coaches affect mindsets helps us learn to lead change.

We are quickly closing in on the end of our re-read of Mindset.  I anticipate two more weeks (Chapter 8 and a round up).  The next book in the series will be Holacracy (Buy a copy today). After my recent interview with Jeff Dalton on Software Process and Measurement Cast 433, I realized that I had only read extracts from Holacracy by Brian J. Robertson, therefore we will read (first time for me) the whole book together.

Every week we discuss a chapter then consider the implications of what we have “read” from the point of view of both someone pursuing an organizational transformation and using the material when coaching teams.  

Remember to buy a copy of Carol Dweck’s Mindset and read along!

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

Next SPaMCAST

The next Software Process and Measurement Cast will feature our interview with Allan Kelly.  Our discussion touched on the concepts behind #NoProject.  Allan describes how the concept of projects leads to a number of unintended consequences.  Those consequences aren’t pretty.

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, for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.

 

Categories: Process Management

Mindset: The New Psychology of Success: Re-Read Week 8, Chapter 7, Parents, Teachers, Coaches: Where Do Mindsets Come From?

Mindset Book Cover

We are quickly closing in on the end of our re-read of Mindset.  I anticipate two more weeks (Chapter 8 and a round up).  The next book in the series will be Holacracy.  After my recent interview with Jeff Dalton on Software Process and Measurement Cast 433, I realized that I had only read extracts from Holacracy by Brian J. Robertson, therefore we will read (first time for me).

Today, we review Chapter 7 in Carol Dweck’s Mindset: The New Psychology of Success (buy your copy and read along).  Chapter 7, titled “Parents, Teachers, Coaches: Where Do Mindsets Come From? explores the impact of some of the most intimate and earliest relationships on our mindsets.Understanding how parents, teachers, and coaches affect mindsets helps us learn to lead change.

Dweck begins Chapter 7 by reinforcing the concept that parents learn very early, every word and action send a message. The rubber hits the road when that message gets interpreted by the recipient.  As we established earlier in the book, those with a fixed mindset interpret any message as a judgment.  Those with a growth mindset will interpret words and actions as feedback that can be used to become better and that the person that is sending the message is interested in their development.

Messages that focus on the outcome rather than the journey tend to have a very short-term impact.  These types of message provide a quick shot of adrenalin. A number of years ago, my wife, eldest daughter and I walked the Inca Trail to Machu Picchu.  It was a difficult hike and provided us an opportunity to contemplate the world and our place in the world. As we toured Machu Picchu at the end of the hike we ran into people that had simply taken the train and could not understand why we had spent the time and effort on the walk.  In our minds, the journey was integral to the whole experience rather than just jumping on and off a train. The realization that the journey important is a part of the learning process defines a person with a growth.  Parents and teachers should send the message that the journey is important by praising both efforts and achievements. A simple message that skills and achievement come through commitment and effort impacts the individual the message is targeted toward and those around them.  All messages once sent are heard and passed on.  Anyone in the teacher, parent, or coach role must continually is if the message being sent is to judge, punish or to help the recipient think and learn.

Much of the chapter is focused on what makes a great teacher, parent or coach.  One of the primary messages Dweck sends in this chapter is that parents and teachers must believe (and send the message) that effort is required to learn and grow.  Talent is not innate, but learned and honed.  Parents and teachers need to establish high standards, provide a nurturing environment and the tools to learn.  Teachers, parents, and coaches with a growth mindset tell the truth about the learner’s gaps in performance and then provide them with the tools to overcome that gaps.  The gaps in performance do not define the person because the assumption is that they will continual to learn and grow.

Organizational Transformation:  Messaging is an important part of all transformations.  The message that frames the transformation has to truthfully identify gaps and performance and the tools that will be deployed to close those gaps.  The tone needs to highlight the growth that effort and the journey will bring to the organization. In any longer term transformation effort will require continual messaging, the same tone needs to be leveraged as progress is made.

Team Coaching: The advice in this chapter can be applied at the team level. Team coaches have to approach helping teams with a growth mindset. Coaches need to assess the teams they work with, share performance gaps, help to envision a better future state and then provide the support and tools needed to grow.  Coaches without a growth mindset rarely will be able to generate a nurturing environment that will convince team members that they are not be judged and graded which will reinforce fixed mindsets.   

 

Previous Entries of the re-read of Mindset:

Basics and Introduction

Chapter 1: Mindsets

Chapter 2: Inside the Mindsets

Chapter 3: The Truth About Ability and Accomplishment

Chapter 4: Sports: The Mindset of a Champion

Chapter 5: Business: Mindset and Leadership

Chapter 6: Relationships: Mindsets in Love (or Not)

 


Categories: Process Management

Three Requirements for Effective Incremental Change

26369190215_3972c2acce_k

People involved with conceiving, directing and coaching change overwhelmingly favor incremental change methods.  The support for incrementalism always comes with caveats.  Those caveats can be consolidated into three requirements. Organizations with effective incremental change programs are pursuing a vision, have an appreciation for the need to increase tolerance to change, and embrace innovation.

A vision that describes a future state in which the business problem is solved is the most critical requirement for effective incremental change. The vision provides direction to the participants in the effort by providing a goal for the team to progress toward.  Each incremental change can be compared to the expressed vision so we can tell whether we are on the correct path.  Dominque Bourget, The Process Philosopher, provided the following quote to drive the point home (PS – it sounds very cool in Canadian French, just ask him):

In real estate there are 3 important things: location, location, and location.
In software development there are 3 important things: quality, quality, and QUALITY.
In process improvement there are 3 dangerous things: short view, short view, and short view.”

The second an appreciation for the need to increase tolerance to change.  The incremental change means that how work is done will be in a continual state of flux.  Early in my career, a mentor suggested that people and organizations really don’t like change. Therefore, it was important to give people the feeling of stability. Over time I have developed a more nuanced understanding of the message about change.  People tend not to like changes they perceive to be harmful and embrace changes they believe will be positive for them and/or that they have a hand in shaping.  An incremental change approach that involves those affected will foster higher levels of tolerance to change.  Dácil Castelo, Productivity & Estimation Area Director at LEDAmc, summarized why she prefers incremental change: “the resistance to change is less with incremental change.”

The third requirement to effective incremental change approach is the need to embrace innovation. All process improvement requires innovation; however, incremental change approaches generally require more innovative approaches in order to preserve momentum.  Incremental change is rarely as straightforward as slicing up larger projects into parts.  Innovation, by definition, represents a substantial deviation from the thought processes of the past.  The power of doing much smaller, related changes is that you receive faster feedback.  Faster feedback generates the need for more agility from those guiding or championing a change initiative as they adapt to changes in the environment.   To paraphrase Helmuth von Moltke, “no plan survives contact with the enemy.” In incremental change approaches contact happens over and over hence the need for innovation.

While I agree with the Process Philosopher that a consistent vision is the most important requirement for effective incremental change, but it is not sufficient. Without an approach to deal with change fatigue, often called change management, almost every change program will fail.  Even good change management support won’t suffice without innovation that integrates the feedback generated as people use those changes.  All three requirements must be addressed!


Categories: Process Management

The Container Monitoring Problem

Xebia Blog - Thu, 03/16/2017 - 21:16

This post is part 1 in a 4-part series about Docker, Kubernetes and Mesos monitoring. This article dives into some of the new challenges containers and microservices create and the metrics you should focus on. Containers are a solution to the problem of how to get software to run reliably when moved from one environment […]

The post The Container Monitoring Problem appeared first on Xebia Blog.

Five Simple but Powerful Ways to Split User Stories

Mike Cohn's Blog - Thu, 03/16/2017 - 15:00

This blog post refers to a four-part series of videos on overcoming challenges with user stories. Topics covered are conducting story-writing workshops with story maps, splitting stories, and achieving the right level of detail in user stories.

To be notified when you the videos are again available, sign up below:

Notify Me!

Today’s post introduces the second installment in a free series of training videos all about user stories. Available for a limited time only, you can watch all released videos by signing up to the Better User Stories Mini-Course. Already signed up? Check your inbox for a link to the latest video, or continue reading to find out about today’s lesson.

One of the most common struggles faced by agile teams is the need to split user stories. I'm sure you've struggled with this. I certainly did at first.

In fact, when I first began using Scrum, some of our product backlog items were so big that we occasionally opted for six-week sprints. With a bit more experience, though, that team and I saw enough ways to split work that we could have done one-day sprints if we'd wanted.

But splitting stories was hard at first. Really hard.

But I've got some good news for you. Not only have I figured out how to split stories on my own, I've learned how to explain how to do it so that anyone can quickly become an expert.

What I discovered is that almost every story can be split with one of five techniques. Learn those five simple techniques and you're set.

Even better, the five techniques form an easily memorable acronym: SPIDR.

I've just released a new, 20-minute, free video training that describes each of these techniques as part of the Better User Stories Mini-Course. To watch it simply sign up here and you’ll get instant access.

Remember, if you’ve already signed up to the course you don’t need to sign in again, just check your inbox for an email from me with a link to the latest lesson.

Unless you've already cracked the code on splitting stories, you definitely want to learn the five techniques that make up the SPIDR approach by watching this free video training.

Mike

P.S. This video is only going to be available for a very short period. I encourage you to watch it now at https://www.betteruserstories.com.