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

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 for […]

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 they see it 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, the focus becomes destructive tunnel vision. One of the attributes of a big bang change program is that 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 vision had become tunnel vision. [HUH?] 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, the incremental change approaches are a tool to create a mechanism to 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 interned 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, 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, answered, “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 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

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

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.

Four Attributes That Support Incremental Change Initiatives

A Thali is an incremental meal

Incrementalism–doing small changes in order to achieve a larger effect–comes in many styles and flavors.  The many variations of this approach have titles such experimentation, continuous process improvement, kaizen events, and plan-do-check-act cycles (PDCA).  To paraphrase 20th Century toothpaste commercials, 4 out of 5 process improvement professionals recommend incrementalism.  Agile and Lean are full of examples of branded incremental change models including the Toyota Production System, Scrum and Kanban (when applied to process improvement). We can see the impact of incrementalism on how these frameworks are constructed by observing the individual techniques such as sprints and time boxes, daily stand-ups both in scrum and XP, and retrospectives, to name a few.  Each technique reinforces taking small steps and seeking feedback for re-planning.  If you don’t want to consider frameworks or techniques remember that the agile mantra of inspect and adapt is a statement of incrementalism.   Incrementalism makes changes to how work is done by shifting the focus from the one big project or implementation to taking small steps, gathering feedback and then reacting. This approach to change is not new. Deming popularized the PDCA cycle early in the 20th Century.  Practitioners embrace incrementalism because making many small changes one after another provides feedback fast, which enhances organizational learning and mitigates many of the risks seen in Big Bang models. Four attributes support learning and risk reduction:

  1. Learning – PDCA type or inspect and adapt models all are built on the expectation that when a change is made, the impact will be reviewed and then the feedback will be used to improve how work is done.  Feedback is used as a learning device, where the faster feedback is generated the higher the possibility of learning.
  2. Risk mitigation – Steven Adams, agile consultant (SPaMCAST 412) stated, “Continuous process improvement is a less risky route.  But could be the slower.” Incremental changes typically will not imperil the organization in the way Big Bang or “bet the farm” type changes could.  For example which has more risk: a bank merger or adding hundreds of customers one at a time through a production interface? While this might not be a perfect analogy the larger change that gets feedback only when it’s completed will ALWAYS be riskier. Along with reducing the risk that size generates, smaller increments help ensure that that change programs don’t wander away from the vision that launched them.  Todd Field, senior project manager and Scrum master described it as, “I believe you need to have a Big Bang vision and an incremental improvements plan.“  Techniques like delivery cadence (e.g. Scrum’s sprint cycle) keep changes small and requiring product owner and stakeholder’s acceptance expose risks before they can become issues making incremental changes safer.
  3. Accumulation – Incremental changes building toward an overall goal are often compared to compound interest.  Small changes build on each other until the return is significantly higher than simply making each of the changes in isolation.  Dominique Bourget, the Process Philosopher described this concept as “It is like losing weight… you get more benefit by exercising one hour each day than to exercise 30 hours in a row on the last day of the month.”
  4. Adaptation to the pace of change in external environment – Software development environments are very dynamic.  New methods, techniques and tools are investigated, implemented and discarded as organizations try to get more done within corporate budgetary restraints. We all know the mantra faster, better, and cheaper.  Because of the rate of long term change in the development environment, change programs often lose focus or sponsorship.  Incremental changes are better at reacting to change and adjusting to the level of urgency within an organization.  Kristie Lawrence, IFPUG Past President, suggested that “continuous process improvement allows you to slowly and surely improve. The trick is to manage the scope of what is being improved – changing one thing changes the entire “system” and surface things that you never knew about.”  Implementing small changes provides a feedback loop to continually test the need for further changes.

Incremental changes provide organizations with a tool to minimize the risk of change.  Agile pundits, originally made the point in terms of software development.  The same ideas that make incremental change useful for software development are equally useful for improving the value of continuous improvement all across the business while reducing risk. As a result,  practitioners are predisposed to championing incremental change.


Categories: Process Management

Four Attributes That Support Incremental Change Initiatives

A Thali is an incremental meal

Incrementalism–doing small changes in order to achieve a larger effect–comes in many styles and flavors.  The many variations of this approach have titles such experimentation, continuous process improvement, kaizen events, and plan-do-check-act cycles (PDCA).  To paraphrase 20th Century toothpaste commercials, 4 out of 5 process improvement professionals recommend incrementalism.  Agile and Lean are full of examples of branded incremental change models including the Toyota Production System, Scrum and Kanban (when applied to process improvement). We can see the impact of incrementalism on how these frameworks are constructed by observing the individual techniques such as sprints and time boxes, daily stand-ups both in scrum and XP, and retrospectives, to name a few.  Each technique reinforces taking small steps and seeking feedback for re-planning.  If you don’t want to consider frameworks or techniques remember that the agile mantra of inspect and adapt is a statement of incrementalism.   Incrementalism makes changes to how work is done by shifting the focus from the one big project or implementation to taking small steps, gathering feedback and then reacting. This approach to change is not new. Deming popularized the PDCA cycle early in the 20th Century.  Practitioners embrace incrementalism because making many small changes one after another provides feedback fast, which enhances organizational learning and mitigates many of the risks seen in Big Bang models. Four attributes support learning and risk reduction:

  1. Learning – PDCA type or inspect and adapt models all are built on the expectation that when a change is made, the impact will be reviewed and then the feedback will be used to improve how work is done.  Feedback is used as a learning device, where the faster feedback is generated the higher the possibility of learning.
  2. Risk mitigation – Steven Adams, agile consultant (SPaMCAST 412) stated, “Continuous process improvement is a less risky route.  But could be the slower.” Incremental changes typically will not imperil the organization in the way Big Bang or “bet the farm” type changes could.  For example which has more risk: a bank merger or adding hundreds of customers one at a time through a production interface? While this might not be a perfect analogy the larger change that gets feedback only when it’s completed will ALWAYS be riskier. Along with reducing the risk that size generates, smaller increments help ensure that that change programs don’t wander away from the vision that launched them.  Todd Field, senior project manager and Scrum master described it as, “I believe you need to have a Big Bang vision and an incremental improvements plan.“  Techniques like delivery cadence (e.g. Scrum’s sprint cycle) keep changes small and requiring product owner and stakeholder’s acceptance expose risks before they can become issues making incremental changes safer.
  3. Accumulation – Incremental changes building toward an overall goal are often compared to compound interest.  Small changes build on each other until the return is significantly higher than simply making each of the changes in isolation.  Dominique Bourget, the Process Philosopher described this concept as “It is like losing weight… you get more benefit by exercising one hour each day than to exercise 30 hours in a row on the last day of the month.”
  4. Adaptation to the pace of change in external environment – Software development environments are very dynamic.  New methods, techniques and tools are investigated, implemented and discarded as organizations try to get more done within corporate budgetary restraints. We all know the mantra faster, better, and cheaper.  Because of the rate of long term change in the development environment, change programs often lose focus or sponsorship.  Incremental changes are better at reacting to change and adjusting to the level of urgency within an organization.  Kristie Lawrence, IFPUG Past President, suggested that “continuous process improvement allows you to slowly and surely improve. The trick is to manage the scope of what is being improved – changing one thing changes the entire “system” and surface things that you never knew about.”  Implementing small changes provides a feedback loop to continually test the need for further changes.

Incremental changes provide organizations with a tool to minimize the risk of change.  Agile pundits, originally made the point in terms of software development.  The same ideas that make incremental change useful for software development are equally useful for improving the value of continuous improvement all across the business while reducing risk. As a result,  practitioners are predisposed to championing incremental change.


Categories: Process Management

Caveats and pitfalls of cookie domains

Xebia Blog - Tue, 03/14/2017 - 22:16

Not too long ago, we ran into an apparent security issue at my current assignment - people could sign in with a regular account, but get the authentication and permissions of an administrator user (a privilege escalation bug). As it turned out, the impact  of the security issue was low, as the user would need […]

The post Caveats and pitfalls of cookie domains appeared first on Xebia Blog.