Warning: Table './devblogsdb/cache_page' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_page WHERE cid = 'http://www.softdevblogs.com/?q=aggregator/categories/5' in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc on line 135

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 729

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 730

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 731

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 732
Software Development Blogs: Programming, Software Testing, Agile, Project Management
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
warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/common.inc on line 153.

Innovation and Magical Thinking

Detroit Tigers

I like baseball.  I can’t tell you the number of times I have spent the afternoon listening to a game and hearing the announcers expound on batting averages and on-base percentages as I puttered around the house. As someone with a background in quantitative analysis, I understand that the chances of a game-winning grand slam in the bottom of the ninth inning by a player that has not hit a home run in the major league are small.  However, in my mind’s eye, I can see the event happening and even believe that because I am listening that it will occur. This example is one form of magical thinking.  Magical thinking occurs when we attribute a causal or synchronistic relationship between actions or events that can’t be justified by reason and observation.  The current business environment means that innovation and magical thinking are often intertwined. Innovation without the ground game of implementation and continuous improvement is magical thinking.

Innovation, by definition, represents a substantial deviation from the thought processes of the past.  For example, Scrum and Extreme Programming (XP) are seen as innovations when compared to waterfall software development. Both are considered revolutionary, and when (and often if) adopted required substantial organizational transformations.  Organizational change is rarely easy; therefore, innovations are rarely adopted whole but rather reflect step-wise transformations.  Kent Beck in Extreme Programing Explained, Second Edition (2005) exposed the values of improvement and baby steps.  Once an innovation is identified it need to be implemented and then improved upon.  Believing that an innovation in its own right will change or save any organization is simply magical thinking.  Any innovation is only useful if it is USED and delivers value.

Even today, organizations consider Scrum, XP, and other Agile frameworks to be innovations under the ‚Äúif it is new to me, it is new‚ÄĚ mantra.¬† Regardless of the difficulty defending that definition of innovation, any organizations that think that they can ‚Äúadopt‚ÄĚ Agile without addressing implementation will up-end the status quo causing disruptions and dislocations. The Agile transformation fails because the bridge between innovation and value is defined by some sort of magical thinking.¬† Several years ago I was having a drink with a friend on Broadway in New York City.¬† The friend was describing a new innovative development framework his firm was adopting.¬† When I asked how it was going to be implemented, I was told that the CEO had mandated its use AND because it was so cool everybody would want to use it.¬† That was the whole implementation plan. Simply put, he had fallen prey to magical thinking. Within six months both the framework and he were not with the firm. Agile thinking has reinforced the idea that getting quickly started, generating feedback and then reacting to the feedback reduces risk and generates value quickly. Unless you have the luxury to implement an innovative idea, concept or product in a new organization without a past, just hoping that something will happen won‚Äôt generate change.¬†

In 1932 Frank Whittle was granted a patent for the turbojet.  Using the current state and predictability attributes noted in Innovation and Change, the turbojet was certainly not business as usual and could not be predicted from past events.  Whittle’s work was an innovation; however, due to testing and development issues, the RAF dismissed the idea prior to World War 2. The introduction of the jet fell to others.  Innovation did not translate to competitive advantage because of a failure in implementation. Innovation is an important step on the path to competitive advantage; however, it is simply a step. Unless innovation is combined with an implementation, we are just dealing with magical thinking.


Categories: Process Management

The Purpose Alignment Model

Xebia Blog - Wed, 06/29/2016 - 09:45
When scaling Agile/Scrum, we invariably run into the alignment vs. autonomy problem. In short, you cannot have autonomous, self-directing teams if they have no clue what direction they should go. Or, even shorter, alignment breeds autonomy. But how do we create alignment? And what tools can we use to quickly evaluate whether or not what

Two Differences Between Innovation and Change

Innovations are limited!

Innovations are limited!

Innovation is a word that has seen heavy use for a long time.¬† In the many uses of the word innovation, the term has been ascribed an equally wide range of meanings.¬† At one end of the spectrum are definitions that suggest that anything that deviates from the norm can be construed as an innovation.¬† One adage holds, ‚Äúif it‚Äôs new to me, it is new.‚Ä̬† However, definitions of this sort conflate the terms ‚Äúchange‚ÄĚ and ‚Äúinnovation‚ÄĚ.¬† At the other end of the spectrum, some definitions provide a clear separation between evolutionary and discontinuous change. In narrower definitions, innovation is a subset of change.¬† In software development, business or even–more broadly–life, change is inevitable and continuous while innovation is not inevitable and far more abrupt. In practical terms, change and innovation often differ in a number of critical attributes.

Current State Knowledge Requirements: Change efforts require establishing a timeframe and the knowledge of the environment that will be impacted before and after the change.¬† Understanding both states allows us to determine whether the change effort was successful. For example, we can assess the change in a software program by comparing two versions of the code. Innovation does not require knowledge of the starting point, because the starting point did not previously exist. The introduction of COBOL was an innovation: one day COBOL did not exist, and then–BOOM–it existed.¬† The lack of a past that provides context for a change is a strong identifier that something is an innovation

Predictability:  Change is often relatively predictable, often building from the past towards the future.  Consider the evolution of Ruby since its public release in 1995 (version .95) to its most recent release in April 2016 (version 2.3.1), or the change in processing power predicted by Moore’s Law.  Innovation is far less predictable because it is less anchored to a current state.

Why do we care?  The focus of much online discussion is on the need for innovation. Innovation is important for the economy and for individual firms.  Innovation rearranges the playing field and can disrupt whole industries.  Uber is an oft-cited innovative business model innovation that has yielded creative destruction.  At the risk of calling forth the trolls, I would suggest that Lyft, meanwhile, is more reflective of change than discontinuous innovation.  Innovation is important. However, managing and directing change are2.3.1 important too, because, in the end, the only things we can count on are death, taxes, and change.


Categories: Process Management

The Ultimate Tester: Sharing Knowledge

Xebia Blog - Tue, 06/28/2016 - 09:50
In the past three blog posts we have explored some aspects of being an Ultimate Tester: How we can add value, how our curiosity helps us to test the crazy stuff and how we can build quality in. We learn a lot about these things during work time (and hopefully during personal time as well),

SPaMCAST 400 ‚Äď Jim Benson, Personal Kanban and More

SPaMCAST Logo

http://www.spamcast.net

Listen Now

Subscribe on iTunes                   Check out the podcast on Google Play Music

Software Process and Measurement Cast 400 features our interview with Jim Benson. Jim and I talked about personal Kanban, micromanagement, work-in-process limits, pattern matching, pomodoro and more. A great interview to cap our first 400 episodes!

Jim‚Äôs career path has taken him through government agencies, Fortune 10 corporations, and start-ups. Through them all his passion has remained consistent ‚Äď applying new technologies to work groups. In each case asking how they can be leveraged to collaborate and cooperate more effectively. Jim loves ideas, creation, and building opportunities. He loves working with teams who are passionate about the future, pushing boundaries, and inclusion. His goal with all technologies is to increase beneficial contact between people and reduce the bureaucratic noise which so often tends to increase costs and destroy creativity.

Jim is the author of the Shingo Research Award winning book Personal Kanban (use the link to support the podcast) . He is a noted expert in business process, personal work management, and the application of Lean to personal work and life. Jim believes that the best process is the least process necessary to achieve goals. He has zero tolerance for process waste.

All said, Jim enjoys helping people and teams work out sticky problems, an advocate of people actually seeing their work, and inventing new ways to work at the intersection of Lean thinking, brain science, and leadership.

Contact Jim

Twitter: https://twitter.com/ourfounder

LinkedIn: https://www.linkedin.com/in/jimbenson

Personal Kanban: http://www.personalkanban.com/pk/#sthash.MtOA96sV.dpbs

Modus Cooperandi: http://moduscooperandi.com/

Re-Read Saturday News

This week we continue the Re-read Saturday of  Kent Beck’s XP Explained, Second Edition with a discussion of Chapters 2 and 3.  The first two chapters in section One provide us with an overview of the conceptual framework that underpins XP.  Use the link to XP Explained in the show notes when you buy your copy to read along to support both the blog and podcast. Visit the Software Process and Measurement Blog (www.tcagley.wordpress.com) to catch up on past installments of Re-Read Saturday.

Next SPaMCAST

The next Software Process and Measurement Cast will feature our essay on listening.  Effective listening is CRITICAL to every aspect of software development  and maintenance. Listening is a complex set of tasks that is more than simply receiving audio data. You also need to interpret that data.

We will also have columns from Jeremy Berriault who brings us the QA Corner and Jon M. Quigley’s second column which covers the gamut of product development.

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 400 ‚Äď Jim Benson, Personal Kanban and More

Software Process and Measurement Cast - Sun, 06/26/2016 - 22:00

Software Process and Measurement Cast 400 features our interview with Jim Benson. Jim and I talked about personal Kanban, micromanagement, work-in-process limits, pattern matching, pomodoro and more. A great interview to cap our first 400 episodes!

Jim‚Äôs career path has taken him through government agencies, Fortune 10 corporations, and start-ups. Through them all his passion has remained consistent ‚Äď applying new technologies to work groups. In each case asking how they can be leveraged to collaborate and cooperate more effectively. Jim loves ideas, creation, and building opportunities. He loves working with teams who are passionate about the future, pushing boundaries, and inclusion. His goal with all technologies is to increase beneficial contact between people and reduce the bureaucratic noise which so often tends to increase costs and destroy creativity.

Jim is the author of the Shingo Research Award winning book Personal Kanban (use the link to buy a copy and support the podcast). He is a noted expert in business process, personal work management, and the application of Lean to personal work and life. Jim believes that the best process is the least process necessary to achieve goals. He has zero tolerance for process waste.

All said, Jim enjoys helping people and teams work out sticky problems, an advocate of people actually seeing their work, and inventing new ways to work at the intersection of Lean thinking, brain science, and leadership.

 

Contact Jim

Twitter: https://twitter.com/ourfounder

LinkedIn: https://www.linkedin.com/in/jimbenson

Personal Kanban: http://www.personalkanban.com/pk/#sthash.MtOA96sV.dpbs

Modus Cooperandi: http://moduscooperandi.com/

 

Re-Read Saturday News

This week we continue the Re-read Saturday of  Kent Beck’s XP Explained, Second Edition with a discussion of Chapters 2 and 3.  The first two chapters in section One provide us with an overview of the conceptual framework that underpins XP.  Use the link to XP Explained in the show notes when you buy your copy to read along to support both the blog and podcast. Visit the Software Process and Measurement Blog (www.tcagley.wordpress.com) to catch up on past installments of Re-Read Saturday.

 

Next SPaMCAST

The next Software Process and Measurement Cast will feature our essay on listening.  Effective listening is CRITICAL to every aspect of software development  and maintenance. Listening is a complex set of tasks that is more than simply receiving audio data. You also need to interpret that data.

We will also have columns from Jeremy Berriault who brings us the QA Corner and Jon M. Quigley’s second column which covers the gamut of product development.

 

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

Extreme Programming Explained: Embrace Change Second Edition, Week 2 (Chapters 2 -3)

XP Explained

This week we begin Section 1of Kent Beck’s Extreme Programing Explained, Second Edition (2005), titled Exploring XP, by tackling Chapters two and three.  The first two chapters in section One provide us with an overview of the conceptual framework that underpins XP. 

Chapter 2: Learning to Drive.¬† In this chapter Beck challenges us¬†to consider that developing a product or writing code is like driving.¬† The metaphor of driving is used because driving is not a one-time event where you start the car and point it in the right direction then take a nap.¬† Rather, driving is a process of constantly paying attention, gathering feedback and making a series of small changes so that you arrive at your goal healthy and whole.¬† As noted in the preface, the core XP paradigm is ‚Äústay aware, adapt, change.‚ÄĚ Tying the driving metaphor and XP together is the common problem of mushy requirements. In XP customers drive the content of the system and steer by getting feedback and adapting based on short iterations.¬†

As a veteran of the quality movement of the 1990‚Äôs, XP with its ‚Äústay aware, adapt, change‚ÄĚ empirical model is easily recognizable to me as continuous improvement model that improves effectiveness, communication, competence, and productivity.

Chapter 3: Values, Principles, and Practices. XP, a methodology, represents a very different approach to software development. In order to effectively use the practices that make up XP requires adopting a set of values that are implemented based on a set of principles.¬†Practices are the things we do, and therefore, are clear and objective.¬†They are done or they are not done.¬† For example, a stand-up meeting is a practice; anyone can easily confirm whether a standup meeting is being held. In the book, Beck used the difference between a person who putters around the garden and a master gardener to illustrate the reasons why learning techniques and practices do not yield mastery. Values allow the practitioner to understand the environment, apply and evolve practices when the context demands.¬†No framework stands as merely a set of rote practices even it might seem like just doing practices leads to a useful outcome. This why there are arguments about the ideas of “being Agile” rather than just “doing Agile.” ¬†The lure¬†of¬†¬†just learning and applying practices without a framework of values and principles is not limited to software development.¬†On my bookshelf there is a book titled, You Can‚Äôt Teach A Kid To Ride A Bike At A Seminar. The book is on sales (I believe everyone should have sales training).¬† Like most how-to books it is full of practices and techniques, with one¬†big difference. The book makes the point that without a set of values and principles we are just robots that don‚Äôt have the level of knowledge and understanding needed to apply those practices when the context changes.¬† Values, principles, and principles are necessary to be a gardener, salesperson, or developer.

Values are an overarching set of rules define the boundaries of behavior. Values define what we believe in and are used to judge what we see, think, and do.  Most cognitive biases are driven by the values a person or team holds. A team that values being a process more than people will act much differently than a team with the opposite set of values.  Defining explicit values provide humans with purpose and direction.

Principles act as the connecting tissue between practices and values.  Principles provide the context-specific guidelines for implementing practices based on the values the team holds.  Beck uses the metaphor of a bridge between values and practices. 

I often talk to people that begin a transformation by adopting practices before thinking about values and principles. Perhaps a small group of true believers have drunk the Koolaid and have institutionalized the values and principles that are at the core of the framework.¬† However, that belief structure does not extend very away from that core group.¬† This approach yields highly variable results and rarely delivers long-term change. This variability occurs whether discussing Agile, the CMMI or a new sales approach. The rationale often seems to be that by adopting practices it is clear that ‚Äúchange‚ÄĚ has occurred because it easy to see actions.¬† However because practices are situational, without the guidance of internalized values and principles it is difficult for practices to mold to situations.¬† When practice doesn’t seem to fit, domain specific guidelines are needed or they will be abandoned.¬†

Previous installment of Extreme Programing Explained, Second Edition (2005) on Re-read Saturday:

Extreme Programming Explained: Embrace Change Second Edition Week 1, Preface and Chapter 1


Categories: Process Management

Beginning An Agile Effort: Breaking Down The Big Picture

26955153324_91f40a31cc_k

How the big picture gets made…

A high-level narrative or story is a good first step in the process of turning an idea into something that delivers real business value.  However, it is only a step along the path through the backlog onion.  Software development (including new development, enhancements, and maintenance work) requires translating the big picture into a product backlog that includes features and epics.  As work progresses the backlog is further decomposed and groomed into user stories and tasks.  The process of moving from any big picture to a backlog in software development follows a predictable pattern.   

  1. Decompose the big picture by identifying the functional and architectural features directly identified or inferred in the story.  This initial step yields a combination of business requirements and the beginning of both the technical and business architecture that will be needed to support the features.  Features of all types are a description of need and outcome and do not represent a decision on how that outcome will be implemented (real options).
  2. Organize the features using a mapping technique such as Agile Story Maps to look for gaps.  Ask yourself and the team whether there are features that needed to achieve the goal identified in the big picture story.  This also a chance for the product owner to reject stories that are not needed to attain the overall goal.
  3. Identify the minimum viable product (MVP). The identification of a minimum viable product at this point identifies the set of features that are needed to deploy a product.  An MVP begins the discussion of priority and a release strategy.  Simply put, features in the MVP will need to be decomposed before features that will be needed later.

An Agile Story Map and an MVP allow a team to cut a wedge into the planning onion that slices from the outer layers directly to the core.  In the Scaled Agile Framework Enterprise (SAFe) the wedge might be called a Product Increment (PI) or a release for efforts using other frameworks and methods.

  1. Features and epics, while easily recognizable, rarely can be tackled by a single team in a single sprint; therefore, they need to be decomposed or split.  The process of decomposing epics and features breaks these large pieces of work into smaller pieces that can be understood and developed within the context of an individual sprint. The backlog of user stories is decomposed as needed so that, as a story gets closer to being accepted into a sprint and developed, the story becomes more and more granular.
  2. Backlog grooming the final step before a story is accepted into a sprint or drawn onto the Kanban board.  Grooming ensures that the story is ready for development (properly formed, sized correctly, understood and have acceptance criteria), and that a team can get started quickly.

The big picture defines the outside of the backlog onion.  However, after we peel the outside of the onion we can cut wedges directly to the core. Slicing wedges, like a minimum viable product, allows a team or teams to decompose and groom only the features and epics immediately needed.  Thereby getting the effort started quickly and effectively.   
Next, a simple example!


Categories: Process Management

Beginning Agile Efforts: 4 Critical Factors For Team Dynamics

Team Dynamics

Team Dynamics

Teams are a common theme in the discussion of how Agile delivers value.  Teams are a collection of individuals that bring a range of capabilities.  Some people are specialists, others generalists and a very few are  renaissance people that are great at a wide range of activities.  Understanding the depth and breadth of capabilities in team members provides the team with the flexibility to dynamically allocate capabilities based on the technical context and business need (staff liquidity).  This is an incredibly powerful theory that only works if the team dynamics are conducive.  Team dynamics are an expression of how the team interacts with each other and those outside the team. When assessing the dynamics of a team there are many factors that are important; however, a few are more critical than others.

  1. Team Cohesiveness РCohesiveness is a reflection of how well a team sticks to together to accomplish a goal.  Cohesive teams know each other’s capabilities and capacity.  Cohesiveness is one factor that leads to psychological safety. A feeling of safety  allows team members to take risks without causing insecurity or fear of embarrassment if everything does not work out.  The cohesiveness of the team can be intuited from the length of time a team stays together and how invested team members are in the success of the team.
  2. Roles and Norms. Even the most Agile team is composed of different people playing different roles. Team performs well when team members recognize the roles that a team needs and then serve in those roles and are comfortable shifting roles when needed by the team. Roles include technical tasks, as well as roles such as leader, researcher and reviewer.  Clarity of roles norms helps build trust within the team and outside the team.  Trust reinforces team cohesion.  Roles and norms can be best assessed by an outsider by observing the teamwork. Alternately, retrospectives can be used to surface discussions of potential role and norm problems.
  3. Conflict Resolution. ¬†All teams will have conflict. Teams need to have a pallet of conflict resolution techniques. ¬†Conflict resolutions techniques can include simple ¬†talking, active listening, multi-voting, cost/benefit analysis or coaching. Teams need to prepare for inevitable conflict both by being aware of the signs of conflict and then have the wherewithal to deal ¬†the conflict. ¬†Observation can tell a coach a lot about a team’s ability deal with conflict. Alternately, one means to assess how a team will react is to give them a scenario and ask how they would solve the problem (this is a backdoor mechanism to teach resolution techniques). ¬†Teams with a good capability for conflict resolution will tend to be more cohesive and struggle less with roles.
  4. Impactful Goals.  Work that the team believes is important both to the organization and team members is motivating.  Motivation provides teams with a well of energy that can be invested in delivering value, resolving conflict, playing the roles that are needed and working together. The simplest way to know whether a team believes the goal they are pursuing is impactful is to ask and then to listen to the emotion in the answer. If there is no emotion, the team does not perceive what they are doing as important.

The four most critical drivers of Agile team dynamics can be assessed by observing and talking with the team.  The right dynamics will unlock a team’s potential; however most can’t get there without a help.  Coaching based on interacting and observing the team is a very powerful tool to give teams the tools needed to become more effective.  When beginning an Agile effort, spend the time and effort needed to tune every team to the four critical factors of team dynamics so they have the best start possible.


Categories: Process Management

Incentives and Deterrents for Starting Daily Scrums On Time

Mike Cohn's Blog - Tue, 06/21/2016 - 15:00

I recently emailed everyone who subscribes to my weekly tips a list of suggestions for ways to motivate team members to arrive on time to the daily scrum. For example, many teams have a rule that if you arrive late, you put a dollar in a jar as punishment for being late. Ideally the collected money is donated to a charity at the end of a project or after it reaches a certain amount.

I included a number of other techniques I’ve seen Scrum Masters use. Many were similar to paying a dollar in that they were punishments for being late. Wow, did I get called out for that. The general argument was that a Scrum Master should use an incentive for being on time rather than a punishment for being late.

That’s a really good point. But I have to say that in the vast majority of teams I’ve seen, they use a punishment rather than an incentive. Many of the punishments involve at least the potential for embarrassing the offender--sing a song, do a pushup, tell a joke, etc.

I’ve thought about why this is. It may be because it’s more natural (for many of us?) to harass the one rule-breaker than reward everyone else. Or maybe it’s because embarrassing the late arriver by making that person sing (for example) is more fun for everyone else.

Incentives Rather than Punishments

I do think, though, that it’s a great suggestion that we look for incentives rather than punishments. Besides, punishment may be too strong of a term. I was told by a couple of people that deterrent might be the better term.

In fact, Rob Dull pointed out an underlying benefit to using a deterrent, saying, “It's sooo healthy for people to be able to be silly/awkward in front of their teammates.”

Others considered the entire idea “stupid,” as one email I received succinctly put it. While others pointed out that the only real fix is to tap into an intrinsic motivation to get latecomers to arrive on time.

Isaias Fritsch took that type of approach by preparing a 30-minute presentation for the team on the importance of the daily scrum. He said that after that presentation, the team decided to come up with some changes to their daily scrum approach. The result of this has been that “the daily scrum is now way more interesting to everyone because relevant information is shared and everyone understands its importance/why we are doing it.”

Ted Morris Dawson had an interesting take on the punishment vs. incentive idea. One technique he has used was if all team members are on time for all daily scrums, then it’s the Scrum Master who does the embarrassing thing like sing, tell a joke or so on. Yikes!

So with the idea that we can help teams overcome the problem through either deterrents or incentives, I’ve split the suggestions I was emailed into lists of each.

Deterrents
  • Read a tongue-twister to the team (“Seventy-seven benevolent elephants” or “Scum-sucking scrum teams scrounge scrumptious scraps.”)
  • Dance alone without music for five seconds. Rob Dull reported, “It's quick, amusing for everyone, and it's a healthy encouragement of vulnerability.”
  • Bring coffee or a snack for the team the next day. Be careful--a few people emailed about gaining weight from this one! :)
  • Have a “tardy board” as Nadine Sullivan called it that tracks late arrivals or absences. Add rules like everyone is allowed one late arrival during some period. But after reaching some number of late arrivals or absences, the person has to bring something in such as a snack for the team.
  • Toss a beach ball, stuffed animal or some other item to the person who is to speak next. Throw, don’t toss, it at any late arrivers.
  • Buy the team an afternoon snack or tea.
  • Present a 30-minute knowledge sharing session on a topic. This was pointed out as being particularly helpful in team building.
  • Facilitate the next review or retrospective.
  • Facilitate the next daily scrum, meaning everyone is waiting for tomorrow’s meeting to start if today’s late arriver is late again.
  • Be the team’s “slave for a day” by doing things like getting snacks, soda and coffee for anyone who needed anything from the kitchen.
  • Take detailed, precise notes for the meeting.
  • Solve a tricky math problem on the board.
  • Buy a book for the office library. How about one one my books? :)
  • Close the door. A late arriver has to open it to enter, which focuses attention on the person.
  • Take on a short (perhaps 15-minute) administrative task the team needs done.
  • Simply put an indicator to each person’s name on a wall to show how frequently each team member was late.
Incentives
  • Reward the first people to arrive with small bits of chocolate.
  • Collect a dollar or two for being late, but when the money is donated to a charity, donate it in the name of the person who arrived first at the meeting most often. Since charitable contributions are tax deductible in many countries, this gives incentives for being early and for not being late. Or as Michel Biron pointed out, it was both “carrot and stick.”
  • Give everyone who was prompt for each daily scrum a reward like a two-hour lunch or permission to come in late and leave early one day.
  • Everyone who was on time for each daily scrum goes to a movie during the day, one day during the next sprint.
  • Establish a policy of “if one of us is late, we’re all late,” and then provide a significant team reward to everyone if everyone is on time. One person told me he did this, but extended it to include being on time for all meetings. He knew that it would be hard to do, so he needed a significant motivation and they agreed on a nice lunch paid for by the company. As a consolation prize, if team members were only on time 90 percent of the time, everyone would receive a chocolate bar.

    I was told, “The result even surprised me. The team completely shifting their behavior. I was seeing team members loading up the digital agile board and setting up the conference connection for the remote team members minutes in advance of the standup. The team was holding each other accountable by friendly shoulder taps to make sure they all make it on time. I even observed a team member running across the building to grab someone out of a meeting to make sure she also makes it on time as well.”
  • Ice cream if everyone is on time every time.
  • A photo of the team holding a sign saying: “We did it!”
  • Start the meeting 15 minutes before everyone wants to go to lunch. Viktor Buzga reports that the company cafeteria in his company gets very crowded at 11:30 when it opens. Arrive at 11:30 and there’s no wait for lunch. Arrive two minutes later and there’s a 10-minute wait. So he starts daily scrums at 11:15. If the team finishes in 10-12 minutes, they’re perfectly timed for lunch. If not ...

So, there are many ways you can go about this. And, as I said in my emailed weekly tip, I love getting the chance to learn from all of you. I definitely learned some good techniques from this. Also, I’ve learned that I really should think more about incentives rather than deterrents.

Whatever you choose to do, you really need to make sure the entire team buys into it. The last thing you want is for someone to go to human resources complaining that you’re making him do a pushup for every minute he arrives late to a meeting.

But, for a team on which being late is a problem, these approaches can help address the problem. A common thread in many replies I received was that many of these incentives and deterrents work especially well because the entire team starts holding each other accountable. This is a huge benefit over just a Scrum Master holding people accountable.

What Do You Think?

What’s missing? What other techniques have you tried to encourage people to be on time for daily scrums? Please share your thoughts in the comments below.

Agile Hiring, Load Testing & Goal Management in Methods & Tools Summer 2016 issue

From the Editor of Methods & Tools - Tue, 06/21/2016 - 08:02
Methods & Tools has published its Summer 2016 issue that discusses hiring for agility, load testing scripts errors, managing with goals on every level and Behavior-Driven Development (BDD) with the open source Turnip tool. Methods & Tools is a free e-magazine for software developers, testers and project managers. * Hiring for Agility ‚Äď Mindset Matters […]

How to Keep flowtype Running and Report Errors on Save

Xebia Blog - Tue, 06/21/2016 - 08:00
We use flow from Facebook to run type checking on our codebase. When you run ‚Äėflow status‚Äô it starts a flow server in the background and keeps it running. That way after the first run the results of each next run are almost instant. The only thing currently lacking is a watch mode, but there

SPaMCAST 399 ‚Äď Storytelling and The Big Picture, Manifesto, Deliberate Practice

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 399 features our essay titled, Storytelling: Developing The Big Picture for Agile Efforts. Agile reminds us that the focus of any set of requirements needs to be on an outcome rather than a collection of whats and whos.  Storytelling is a powerful tool to elevate even the most diehard requirements analyst from a discussion of individual requirements to a discussion of outcomes. Before we can generate a backlog composed of features, epics, and user stories, we need to understand the big picture.

Our second column is a visit to Gene Hughson’s Form Follows Function Blog.  We discussed an entry titled A Meaningful Manifesto for IT.  Do we need a manifesto to know that how well we are meeting the needs of our customers is a reflection of how fit IT is for purpose? Perhaps the answer is yes, if for no other purpose than to ensure we make sure that what we deliver is not a waste of money.

Anchoring the cast this week is the Software Sensei, Kim Pries.  Kim discusses the role of deliberate practice in increasing the capability and capacity of teams. Kim’s provides practical advice on improving team performance.

Re-Read Saturday News

This week we begin the Re-read Saturday of  Kent Beck’s XP Explained, Second Edition with a discussion of the Preface and Chapter 1.  These sections provide a definition of XP and context for the diving into the principles and techniques. Using the link to XP Explained when you buy your copy to read along will support both the blog and podcast. Visit the Software Process and Measurement Blog (www.tcagley.wordpress.com) to catch up on past installments of Re-Read Saturday.

Next SPaMCAST

The next Software Process and Measurement Cast, #400!, features our interview with Jim Benson. Jim and I talked about personal Kanban, micromanagement, work-in-process limits, pattern matching, pomodoro and more. This was a marvelous interview to commemorate our first 400 shows!

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 399 ‚Äď Storytelling and The Big Picture, Manifesto, Deliberate Practice

Software Process and Measurement Cast - Sun, 06/19/2016 - 22:00

The Software Process and Measurement Cast 399 features our essay titled, Storytelling: Developing The Big Picture for Agile Efforts. Agile reminds us that the focus of any set of requirements needs to be on an outcome rather than a collection of whats and whos.  Storytelling is a powerful tool to elevate even the most diehard requirements analyst from a discussion of individual requirements to a discussion of outcomes. Before we can generate a backlog composed of features, epics, and user stories, we need to understand the big picture.

Our second column is a visit to Gene Hughson’s Form Follows Function Blog.  We discussed an entry titled A Meaningful Manifesto for IT.  Do we need a manifesto to know that how well we are meeting the needs of our customers is a reflection of how fit IT is for purpose? Perhaps the answer is yes, if for no other purpose than to ensure we make sure that what we deliver is not a waste of money.

Anchoring the cast this week is the Software Sensei, Kim Pries.  Kim discusses the role of deliberate practice in increasing the capability and capacity of teams. Kim’s provides practical advice on improving team performance.

 

Re-Read Saturday News

This week we begin the Re-read Saturday of  Kent Beck’s XP Explained, Second Edition with a discussion of the Preface and Chapter 1.  These sections provide a definition of XP and context for the diving into the principles and techniques. Using the link to XP Explained when you buy your copy to read along will support both the blog and podcast. Visit the Software Process and Measurement Blog (www.tcagley.wordpress.com) to catch up on past installments of Re-Read Saturday.

 

Next SPaMCAST

The next Software Process and Measurement Cast, #400!, features our interview with Jim Benson. Jim and I talked about personal Kanban, micromanagement, work-in-process limits, pattern matching, pomodoro and more. This was a marvelous interview to commemorate our first 400 shows!

 

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

Re-Read Saturday: Extreme Programming Explained: Embrace Change Second Edition Week 1

XP Explained

This week we begin the re-read of Kent Beck’s Extreme Programing Explained, Second Edition (2005). I remember the first time I read Extreme Programing Explained (First Edition), it was flying back and forth between Cleveland and Los Angeles.  It took two flights and then a lot of time to consider. XP Explained provides not only an explanation of Extreme Program, but also a philosophy for XP and Agile.  The 189 pages are organized into two sections and 25 relatively short chapters and are crammed with information and ideas. I used a whole highlighter on the book during my first read (the pages are now florescent yellow.  The book was written by Kent Beck, one of my heroes even before Agile.  The Second Edition now has Cynthia Andres joining Mr. Beck.

Extreme Programming Explained: Embrace Change, Second Edition begins with two forwards and a preface. ¬†I freely admit that my natural tendency is to plow through reading forewords and prefaces. ¬†In this case, it was interesting to compare the difference between the forewords from the first and second editions, both written by Erich Gamma. ¬†¬†The main point is that the second edition is a full rewrite. ¬†Gamma says¬†that Beck applied the XP paradigm of ‚Äústay aware, adapt, change.‚ÄĚ

Extreme Programming reflects a philosophy of adapting and changing based on the environment that the developer is operating in.  In the Preface, Beck rephrased the message that he used to open the first edition.  The message Beck opens the book with is that:

  1. No matter the circumstances you can always improve.
  2. You can always start improving with yourself.
  3. You can always start improving today. 

The message of XP Explained is one of hope, discipline, deliberate practice, and improvement.

Chapter 1 – What is XP?

Chapter 1 is the context from which the rest of the book builds. ¬†During my original read, I remember breezing through this chapter to get to the ‚Äúbeef.‚ÄĚ However, over the years, I have returned to this chapter to reground my understanding of Beck‚Äôs vision. ¬†In the second edition, Beck builds on his initial definition: ‚ÄúXP is a lightweight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements.‚ÄĚ In the second edition, Beck provides a list of attributes to augment the original definition.¬†

  • XP is lightweight
  • XP is a methodology
  • XP can work with teams of any size
  • XP adapts to vague or rapidly changing requirements.

The obvious difference is the recognition that XP can be used with teams of any size. As interesting is the implicit recognition in the last attribute that XP is can be applied even when requirements are well understood.  The newer definition recognizes that XP is both a style and philosophy of software development that can be applied to any scenario. The overarching philosophy provides a container to hold a set of complementary principles that support a set of techniques.  

Beck suggests philosophically that in XP you don’t prepare for failure, rather you play all out to win. ¬†XP is a philosophy and methodology that is based on a¬†mentality of sufficiency. Rather than focusing on the constraints, a project lives within, XP focuses on delivering software and continuous improving regardless of constraints. All efforts and projects have constraints, spending too much time worrying about constraints is a distraction from the goal of the work. ¬†

XP addresses many of the risks in the software development process, such as:

  1. Schedule slippage by leveraging short release cycles.
  2. Avoidance of not delivering anything due to project cancellation by the use of small releases that make business sense.  
  3. Chances that the system goes ‚Äúsour‚ÄĚ by leveraging continuous automated testing.
  4. High defect rates by having both programmers and customers write tests.
  5. Business needs are misunderstood by including business-oriented people as first class members of the team.
  6. Business needs change before delivery is addressed through the shortened release cycle.
  7. False feature rich releases are avoided by planning that includes the business and an insistence on working on the highest priority items first.
  8. Staff turnover is reduced by allowing programmers to take the responsibility of estimating their own work and then to perform to those estimates. The frustration of being asked (or told) to do the impossible is reduced improving the working environment.

When I was flying to Los Angeles reading Extreme Programming Explained the first time, I was a little bit too impatient and breezed through Chapter 1.  However, it is important because it provides the contextual underpinning for XP.  Understanding the definition and philosophy of XP  provides a foundation for beginning to explore XP in more depth next week.

Programming Notes:  Next week we will begin Section One: Exploring XP.  Currently, I am planning to re-read two chapters per week even though they are relatively short. Please get a copy of Extreme Programing  Explained, Second Edition (this link will support the blog and podcast), read along and comment!   

 


Categories: Process Management

Filtering objects to Optionals

Xebia Blog - Fri, 06/17/2016 - 16:36
A while ago I stumbled upon a Blog post by Natascha the Robot about Configuring a Constant Using Shorthand Argument Names in Swift. Which by itself is a great post, but I was most inspired by the Then library mentioned at the end of her post. Seeing how such a small amount of code could change the way we configure

Staff Liquidity Is All About The People

Baseball player swinging at a pitch

Sometimes having a DH makes sense!

We began discussing the concept of staff liquidity during the re-read of Commitment. Liquidity is a financial concept describing the ease of converting assets into cash. Stocks traded on a major exchange are liquid while stocks in private company traded between friends are far less liquid. Translating the financial concept to software development and maintenance teams, liquidity is a measure of the ease of turning effort into functionality. Staff liquidity is valuable three significant reasons:

Staff liquidity reduces risk. In Waltzing with Bears, Tom DeMarco, and Tim Lister defined five categories of risk.

  • Intrinsic Schedule Flaws
  • Specification Breakdowns
  • Scope Creep
  • Personnel Loss
  • Productivity Variance

Staff liquidity helps the team move people to bottlenecks caused by capacity problems, which reduces three of those risks (schedule flaws, personnel loss, and productivity variance).  For example, a team with a testing capacity problem will tend to fail to deliver or end up delivering partially tested code. When a bottleneck is identified, resources with some testing experience from within the team can be used to increase testing capacity. This is why everyone on a team can’t be purely a specialist (I-shaped person).

Staff liquidity increases productivity. The ability to get work done so that the business or a customer can provide feedback has been shown to ¬†increase both quality and productivity over time. Don Reinertsen in The Principles of Product Development Flow (who was interviewed on SPaMCAST 92) stated at the outset of Chapter 8, ‚ÄúA little rudder early is better than a lot of rudder late.‚ÄĚ The faster a team gets feedback, the smaller the impact of any potential change or defect. Staff liquidity prevents teams from getting stuck, delaying the completion of work and getting to a point where feedback can be gathered in production.

Staffing liquidity increases trust. Trust is a multifaceted term; however, one ingredient in trust is doing what you said you would and being able to prove it. Being able to adjust capacity in order to rally to problems or to remove bottlenecks increases a team’s ability to deliver. Additionally, the reduction of systemic risk lowers that amount of tension present in any work environment which increases trust between customers, management, and the team.

As noted in our read of Commitment, staff liquidity is good for everyone. But unless you have the luxury of having constructed a team with T, M and Pi-shaped people, how can you assess staff liquidity? Assessing the capabilities of the team can be as simple as canvassing the team during a retrospective. Ask team members which roles they could handle in a pinch and then ask the remaining team members to provide feedback. This approach requires a significant amount of trust among team members or the feedback will be perfunctory. A second easy mechanism is to actually watch what happens when a team runs into a bottleneck. Just waiting to see what will happen is a bit scary. This is the approach many inexperienced scrum masters and coaches use under the mistaken assumption that urgency will spur people to move outside their comfort zone. Combining the two techniques is actually far more useful. Asking about the breadth and getting team members to public commit to having more than a single specialty plants a seed which urgency can be used to push people into action (a type of anchor bias). Once the team understands each other’s capabilities, have team members with the most options pull their work last and keep a buffer of capacity free to help others.

Staff liquidity is not rocket science; however, it does require that teams and team members spend time understanding their capabilities. Time for introspection on capabilities and capacity must happen before starting an Agile effort and should be revisited during any effort. Real life will provide feedback and experience helps people to grow and change increasing options and staff liquidity.


Categories: Process Management

Productive Agile Teams:  I, T, E and M Shaped People

Pi(e)-shaped person?

Pi(e)-shaped person?

Many Agile discussions talk about team members as generalizing specialists.¬† Generalizing specialists are individuals that have a specialty; however, they also have broad levels of experience that can be applied.¬† Tim Brown of IDEO coined term ‚ÄėT-shaped people‚Äô (or skills) to describe this combination of specialization and experience.¬† There are a number of other letter- or symbol-based metaphors, sort of an alphabet soup of metaphors, that describe the type of person you might find in a team.

  • Dash-shaped people are generalists.¬† They have a breadth of experience, but little depth.¬† My mother used to describe these type of people as “a mile wide and inch deep.” In baseball, a generalist would be a utility player; highly valued because they fill in many positions, but not a starter.
  • I-shaped people are specialists. Specialists have a single specialty or focus.¬† My mother often called this type of person ‚Äúan inch wide and mile deep.‚Ä̬† Considering the concept of staff liquidity from Commitment, an I-shaped person is the most limited of the letters.¬† For example, a person that is DBA that specializes only in NoSQL databases will be less valuable if the team needs help with business analysis.
  • T-shaped people represent the classic agile team member.¬† T-shape people have a specialty, and in addition, they have a wider breadth of experience with other skills.¬† T-shape people have a focus but can fill in when bottlenecks are recognized. ¬† ¬†
  • M-shaped people have¬†multiple specialties.¬† From the point of view of flexibility, a person with more than one specialty can be applied more flexibly than someone with single specialty. Each additional specialty shifts our mental picture from a letter to a comb.
  • Pi-shaped people combine breadth with multiple specialties (combining T and M-shaped people).
  • E-shaped people are people that combine experience, expertise, exploration, and execution. However, a lot of emphases is placed on the last E: execution. E-shaped people translate ideas into reality.¬† I would suggest that Leonardo da Vinci was an E-shaped person.

Understanding where the individuals on a team fall in the alphabet soup is a powerful input for applying the concept of staff liquidity.  A team applying staff liquidity will always allocate the people with the least options (the fewest things they can do or most specialized) to work first.  These are generally the I-shaped people. Those with more options fill in the gaps in capability after the first wave of allocation and are available to react when things happen. The allocation process provides the team with the most flexibility. Even in high-performing teams, not everyone is an M, T, Pi, or E-Shaped person. In my experience, teams are a mix of generalists, specialists, and multi-talented superstars. Everyone on the team needs to recognize the mixture of talents and capabilities in order to manage the work and remove bottlenecks as the development process moves forward.


Categories: Process Management

Productive Agile Teams:  I, T, E and M Shaped People

Pi(e)-shaped person?

Pi(e)-shaped person?

Many Agile discussions talk about team members as generalizing specialists.¬† Generalizing specialists are individuals that have a specialty; however, they also have broad levels of experience that can be applied.¬† Tim Brown of IDEO coined term ‚ÄėT-shaped people‚Äô (or skills) to describe this combination of specialization and experience.¬† There are a number of other letter- or symbol-based metaphors, sort of an alphabet soup of metaphors, that describe the type of person you might find in a team.

  • Dash-shaped people are generalists.¬† They have a breadth of experience, but little depth.¬† My mother used to describe these type of people as “a mile wide and inch deep.” In baseball, a generalist would be a utility player; highly valued because they fill in many positions, but not a starter.
  • I-shaped people are specialists. Specialists have a single specialty or focus.¬† My mother often called this type of person ‚Äúan inch wide and mile deep.‚Ä̬† Considering the concept of staff liquidity from Commitment, an I-shaped person is the most limited of the letters.¬† For example, a person that is DBA that specializes only in NoSQL databases will be less valuable if the team needs help with business analysis.
  • T-shaped people represent the classic agile team member.¬† T-shape people have a specialty, and in addition, they have a wider breadth of experience with other skills.¬† T-shape people have a focus but can fill in when bottlenecks are recognized. ¬† ¬†
  • M-shaped people have¬†multiple specialties.¬† From the point of view of flexibility, a person with more than one specialty can be applied more flexibly than someone with single specialty. Each additional specialty shifts our mental picture from a letter to a comb.
  • Pi-shaped people combine breadth with multiple specialties (combining T and M-shaped people).
  • E-shaped people are people that combine experience, expertise, exploration, and execution. However, a lot of emphases is placed on the last E: execution. E-shaped people translate ideas into reality.¬† I would suggest that Leonardo da Vinci was an E-shaped person.

Understanding where the individuals on a team fall in the alphabet soup is a powerful input for applying the concept of staff liquidity.  A team applying staff liquidity will always allocate the people with the least options (the fewest things they can do or most specialized) to work first.  These are generally the I-shaped people. Those with more options fill in the gaps in capability after the first wave of allocation and are available to react when things happen. The allocation process provides the team with the most flexibility. Even in high-performing teams, not everyone is an M, T, Pi, or E-Shaped person. In my experience, teams are a mix of generalists, specialists, and multi-talented superstars. Everyone on the team needs to recognize the mixture of talents and capabilities in order to manage the work and remove bottlenecks as the development process moves forward.


Categories: Process Management

Software Development Linkopedia June 2016

From the Editor of Methods & Tools - Mon, 06/13/2016 - 14:35
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 software bugs, rewriting code, project routines, improving retrospectives, acceptance testing problems, #noprojects, DevOps and Agile (or not) software architecture. Blog: Software has bugs. This is normal. Blog: When to Rewrite […]