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 422 – Philip Lew, Agile Risk Management and Quality

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 422 features our interview with Phil Lew.  Phil and I talked about the topic of Agile risk management.  We explored how risk can be managed in Agile projects and the barriers to effective risk management.  As important as the mechanics of Agile risk management are, Philip and I also explored the relationship between quality and risk, which may be more important in the long run.

Phil’s Bio

Philip Lew is the CEO at XBOSoft. XBOSoft’s software QA and software testing services help their clients deliver products to market faster and with higher quality; an ever increasing challenge as software becomes more complex and platforms increase. As a Corporate Executive, Development Manager, Product Manager and Software Engineer, Philip has managed teams to tackle broken processes, develop solutions to difficult problems, and coached others be leaders, managers, and experts. He leverages his academic background in operations research, industrial engineering, and computer science combined with hands-on work experience with programming, predictive modeling and algorithm development to work with clients and colleagues around the world. For kicks, he rides a bicycle and travels the world to quench his thirst for exploration and learning.

Contact Data
LinkedIn: https://www.linkedin.com/in/philiplew
Email: philiplew@gmail.com
Twitter: @philiplew

Re-Read Saturday News

In this week’s re-read of The Five Dysfunctions of a Team  by Patrick Lencioni (Jossey-Bass, Copyright 2002, 33rd printing), we conclude Part Four with the sections titled Harvest, Gut Check, and March. I suspect we have 2 or 3 weeks left before moving to the next book, BUT we still have a number of ideas to extract from this book.

If you are new to the re-read series buy a copy and bo back to week one and read along!

I am running a poll to decide between Carol Dweck’s Mindset, Thinking Fast and Slow (Daniel Kahneman) and Flow (Mihaly Csikszentmihalyi).  I have also had suggestions (in the other category) for Originals: How Non-Conformists Move the World (Adam Grant) and Management Lessons from Taiichi Ohno: What Every Leader Can Learn from the Man by Takehiko Harada.  I would like your opinion! (see the poll below)

Take Our Poll (function(d,c,j){if(!d.getElementById(j)){var pd=d.createElement(c),s;pd.id=j;pd.src='https://s1.wp.com/wp-content/mu-plugins/shortcodes/js/polldaddy-shortcode.js';s=d.getElementsByTagName(c)[0];s.parentNode.insertBefore(pd,s);} else if(typeof jQuery !=='undefined')jQuery(d.body).trigger('pd-script-load');}(document,'script','pd-polldaddy-loader'));

Takeaways from this week include:

  •  Progress is rarely linear (think two steps forward and one step back).
  •  Good teams can debate and then be friends.
  •  The good of the organization is important (Spock got it right).

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

Next SPaMCAST

The Software Process and Measurement Cast 423 will post on Christmas Day.  SPaMCAST 423 will build on our interview from this week with Mr. Lew and discuss measuring quality.  Quality is related to risk, productivity, and customer satisfaction.  We will also have columns from Kim Pries, Jon M Quigley, and Jeremy Berriault. A big show to end the year!

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 422 - Philip Lew, Agile Risk Management and Quality

Software Process and Measurement Cast - Sun, 12/18/2016 - 23:00

The Software Process and Measurement Cast 422 features our interview with Phil Lew.  Phil and I talked about the topic of Agile risk management.  We explored how risk can be managed in Agile projects and the barriers to effective risk management.  As important as the mechanics of Agile risk management are, Philip and I also explored the relationship between quality and risk, which may be more important in the long run.

Phil’s Bio

Philip Lew is the CEO at XBOSoft. XBOSoft’s software QA and software testing services help their clients deliver products to market faster and with higher quality; an ever increasing challenge as software becomes more complex and platforms increase. As a Corporate Executive, Development Manager, Product Manager and Software Engineer, Philip has managed teams to tackle broken processes, develop solutions to difficult problems, and coached others be leaders, managers, and experts. He leverages his academic background in operations research, industrial engineering, and computer science combined with hands-on work experience with programming, predictive modeling and algorithm development to work with clients and colleagues around the world. For kicks, he rides a bicycle and travels the world to quench his thirst for exploration and learning.

Contact Data
LinkedIn: https://www.linkedin.com/in/philiplew
Email: philiplew@gmail.com
Twitter: @philiplew

Re-Read Saturday News

In this week’s re-read of The Five Dysfunctions of a Team  by Patrick Lencioni (Jossey-Bass, Copyright 2002, 33rd printing), we conclude Part Four with the sections titled Harvest, Gut Check, and March. I suspect we have 2 or 3 weeks left before moving to the next book, BUT we still have a number of ideas to extract from this book.

If you are new to the re-read series buy a copy and bo back to week one and read along!

I am running a poll to decide between Carol Dweck’s Mindset, Thinking Fast and Slow (Daniel Kahneman) and Flow (Mihaly Csikszentmihalyi).  I have also had suggestions (in the other category) for Originals: How Non-Conformists Move the World (Adam Grant) and Management Lessons from Taiichi Ohno: What Every Leader Can Learn from the Man by Takehiko Harada.  I would like your opinion! (see the poll below)

[polldaddy poll=9605629]

Takeaways from this week include:

  •  Progress is rarely linear (think two steps forward and one step back).
  •  Good teams can debate and then be friends.
  •  The good of the organization is important (Spock got it right).

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

Next SPaMCAST

The Software Process and Measurement Cast 423 will post on Christmas Day.  SPaMCAST 423 will build on our interview from this week with Mr. Lew and discuss measuring quality.  Quality is related to risk, productivity, and customer satisfaction.  We will also have columns from Kim Pries, Jon M Quigley, and Jeremy Berriault. A big show to end the year!

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

An alternative AngularJS test runner

Xebia Blog - Sun, 12/18/2016 - 12:13
When building an Angular application, we usually stick to the suggested or auto-generated solution of unit testing; the Karma test runner and server, the Jasmine testing framework, and PhantomJS as the environment to run it all in. In this blog post I'll explain how this is rather silly, and will provide an alternative and lightweight

Five Dysfunctions of a Team, Patrick Lencioni: Re-Read Week 12

Five Dysfunctions of a Team

Five Dysfunctions of a Team

In this week’s re-read of The Five Dysfunctions of a Team by Patrick Lencioni (Jossey-Bass, Copyright 2002, 33rd printing), we address section four with the sections titled The Harvest, Gut Check, and The March.  These three sections complete and sum up The Fable.  I am planning three more weeks on this book.  

Which means we need to choose a new book. We have a poll going for the next book. I have identified three books, including re-reading Carol Dweck’s Mindset, Thinking Fast and Slow (Daniel Kahneman) and Flow (Mihaly Csikszentmihalyi).   I have also had suggestions (in the other category) for Originals: How Non-Conformists Move the World (Adam Grant) and Management Lessons from Taiichi Ohno: What Every Leader Can Learn from the Man by Takehiko Harada.  I would like your opinion.

Take Our Poll (function(d,c,j){if(!d.getElementById(j)){var pd=d.createElement(c),s;pd.id=j;pd.src='https://s1.wp.com/wp-content/mu-plugins/shortcodes/js/polldaddy-shortcode.js';s=d.getElementsByTagName(c)[0];s.parentNode.insertBefore(pd,s);} else if(typeof jQuery !=='undefined')jQuery(d.body).trigger('pd-script-load');}(document,'script','pd-polldaddy-loader'));

If you are new to the re-read series buy a copy of the current book and go back to week one and read along!

Part Four

In this section, Lencioni completes The Fable and sets the book up for a final discussion of the model.

Harvest

This section outlines the final offsite with the team.  I use the term “team” to express the evolution from a group of individuals into a more cohesive unit.  In the book, two markers show that the team has becomes more of a unit.  During the meetings, more laughter can be heard even after contentious debate, and during breaks the team members stayed together rather heading back to their rooms or places unknown. Lencioni also uses this section to remind readers of the overall model (shown below) which will be reviewed in detail during the last few weeks of the re-read.

Regardless of progress, this section reminds us that all teams struggle and tend not to progress in a straight line.  Even the best teams I have been part of have struggled with some topics or decisions.  Often team struggles generate short-term trust issues which need to quickly dealt with or the team can fall apart.  Lencioni indicates that the team (and by extension the team leader) must have the discipline to ensure the dysfunctions do not filter back into the team’s behavior patterns.

Gut check

The firm, Green Banana, that Nick had suggested DecsionTech buy earlier in the story is back; however, this time they are pursuing an unsolicited offer to acquire DecsionTech.  The team rejects the offer seeing a better future working together. Mikey’s replacement, the new marketing guy, is amazed at how energetically the team debated the decision about Green Banana and other topics.  The team held each other accountable and ended with clear decisions without any animus.  Lencioni uses the Gut Check section to highlight the behavioral differences compared to earlier in the book.  Teams that address the dysfunctions can debate and hold each other accountable without damaging relationships so that they end up with better decisions.

The March

This section completes The Fable.  In my mind, this is the section where everyone lives semi-happily ever after.  Over the next years, Lencioni describes an organization where things are better, but not perfect.  In this section, DecisionTech is tied for the top spot in the industry but wants to be on top. Kathryn rearranges her staff to make the executive team more compact.  Jeff suggests that he work for Nick (who is the new COO) rather than continue as a direct report to make the team more streamlined.  I am reminded of Dumas and the Three Musketeers, “all for one and one for all.”  While I think The Fable ends a tad contritely – I wanted lasers and starships – it is good to remember that everyone (includes those with stock options) should be working for the good of the organization, not just the quick payout. 

Three Key takeaways:

  1.   Progress is rarely linear (think two steps forward and one step back).
  2.   Good teams can debate and then be friends.
  3.   The good of the organization is important (Spock got it right).

Previous Installments in the re-read of  The Five Dysfunctions of a Team by Patrick Lencioni:

Week 1 – Introduction through Observations

Week 2 – The Staff through the End Run

Week 3 – Drawing the Line though Pushing Back

Week 4 – Entering Danger though Rebound

Week 5 – Awareness through Goals

Week 6 – Deep Tissue through Exhibition

Week 7 – Film Noir through Application

Week 8 – On-site through Fireworks

Week 9 – Leaks through Plowing On

Week 10 – Accountability through The Talk

Week 11 – Last Stand through Rally

 


Categories: Process Management

Post-Agile Age: A Lack of Systems Thinking/Management

 

The Agile movement was built on a premise that skilled, motivated individuals working on teams could self-organize and self-manage in order to deliver value and make their customers happy. Acceptance of this premise means that leaders, who are generally already successful, need to change how they make decisions on a day-to-day basis. Changing how successful leaders and managers work is hard.  Some organizations and leaders have been able to change how they worked and embraced a systems-thinking view of their organization. This change has shifted significant levels of decision making from middle management into the team. The change in the approach to thinking and decision-making Agile is based on several criteria:

  1.  Cross-functional teams.  Scrum, the most commonly adopted Agile framework, demands that functionality is potentially implementable at the end of each sprint (or iteration). In order to transform a story into implementable code requires a range of skills.  Teams of all coders, business analysts, database analysts or testers can’t transform a user story into code that can be put into production at the end of an iteration.  Cross-functional teams are often at odds with organizations that have organized teams by specialties and then move work around in a matrix or factory fashion.  For example, in many organizations coders code and once coding is done pass the code to the testing team.
  2.  Diverse perspectives. Much has been written on the need for teams to have a diverse perspective.  In many cases, significant progress has been made on this front.  The gotcha is that diverse perspectives include not only different technical specialties and backgrounds but also business acumen.  This last item has been a stumbling block with the rise of the proxy product owner who is often a business analyst or someone in the technology hierarchy without access to internal and external customer knowledge because of the barrier between development and the business.
  3.  Using systems thinking to guide work. Organizations are a series of interlocking systems. The software is generally an integral cog in a bigger picture. Systems thinking is an approach to problem-solving that emphasizes the whole process, including the environment the system, like software development, operates within.  Organizing work to maximize the flow through the system increases value to the entire organization.  Improving any specific step without having a few view of the whole can lead to improvements in a step that to do not translate to the bottom line (this is called local maximization).  Often software development offers a constrained example of a breakdown of systems thinking in which specialist such as coders, testers, and business analysts each tries to make their internal processes more efficient without reference to the bigger picture.   This lack of systems thinking is typically a reflection of how people are organized and how they are incented.  Organization and incentive plans, while not carved in stone, are tied to an organizational culture which makes them difficult to change.
  4.  Servant Leadership (ish). A servant leader is the representative of a goal; a servant leader draws followers to the goal and then helps them to improve. The term was popularized in the 1970’s by Robert Greenleaf and has evolved into a current definition which focuses on helping the team/followers to improve.  Servant leadership is a very powerful tool to help unlock the power of teams and therefore is a core attribute of effective Agile.  The problem is that servant leadership is difficult to implement and often at odds with the hierarchical management structures common in the corporate environment.  

The Agile movement has moved many early adopters away from solely relying on eminence-based leadership, which is associated with seniority and hierarchy as is normal in command and control environments. Much of the easy change is over and a more pragmatic and slow evolution that is wrestling with changing organizations cultures that are less driven to change is now occurring.  The shift away from the loud insistence of team-based, servant leadership is a direct signal that Agile as a movement has run its course.  Just because the movement is over does not mean that systems thinking and Agile leadership styles will not continue to slowly penetrate organizations.  They will continue to penetrate but only as they overcome culture, organizational hierarchies, incentive plans and lack of business involvement which will be a long term grind!

 

Planned essays in Post Agile Age Arc include:

  1. Post Agile Age: The Movement Is Dead
  2. Post Agile Age: Drivers of the End of the Agile Movement and Method Lemmings
  3. Proscriptive Norms
  4. A Brand Driven Ecosystems
  5. A Lack of Systems Thinking/Management (Current)
  6. The Age of Aquarius (Something Better is Beginning)

Categories: Process Management

The Customer Pain Map

Xebia Blog - Thu, 12/15/2016 - 15:28
“Ouch, that really hurt.” “What was it?” my sparring partner replied. “The choke or the overstretching of the elbow joint?” “The quick throw, I had no time for proper fall breaking.” I replied. It happens in our sport, we try and experiment and try to find the best way to perform a technique. The goal

Linking Animations to Scroll Position in React Native

Xebia Blog - Thu, 12/15/2016 - 11:37
When you want to link a custom animation to the scroll position in a ScrollView, like in the card example below, you are in for some bad performance on low end devices. Let’s figure out why and learn how to make it buttery smooth. Read more

Software Development Linkopedia December 2016

From the Editor of Methods & Tools - Wed, 12/14/2016 - 12:21
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 project management personalities, better teams, starting a new job, code reviews, agile testing, scaling Agile, IoT and tests quality. Blog: Implementers, Solvers, and Finders Blog: Giving better code reviews Blog: […]

Post-Agile Age: Brand-Driven Ecosystems

Brand-driven ecosystems set down roots.

Brand-driven ecosystems set down roots.

Certifications are only one of the drivers that are hardening the boundaries between Agile techniques, frameworks and the outside world.  Brand ecosystems, made up of proprietary methods, tools, and/or tool suites also tend to contribute to hardening of boundaries which slows innovation and evolution of how teams and organizations work. The slowing of innovation and evolution of how work is done is a marker of the beginning of the end of all of the great movements of the past.  In this case, specifically the hardening of brand ecosystems marks the turning point of Agile as a movement and perhaps a hint that the dawn of the post-agile age is nigh.

Brand-driven ecosystems carry many of the same upsides and downsides that were discussed for certifications. Most Agile brands are based on or implemented by a tool or suite of tools.  Three most critical selling points for brand-driven ecosystems are:

  •        Structure helps teams and organizations to behave. 
  •        Standard methods are a mechanism to document structure.
  •        Tools implement standard methods and approaches. 

The three critical selling points support two sets of goals all Agile brands have. The customer-centric goals of brand-driven ecosystems are to make work and communication easier. However, the internal business goals generally are to capture and lock customers into an ecosystem to support the economic needs to the organization(s) selling the brand ecosystem.

While there are positives to brand-driven ecosystems,  there are also problems caused by embracing these ecosystems.  The problems stem from the unintended consequences caused mostly by the by the second set of goals which lock in specific points of view and slow or stop the evolution of ideas.  Four consequences bear deeper exploration:

  1. Change becomes difficult. The first unintended consequence of locking into an ecosystem is that change becomes difficult.  This a is a common issue seen with nearly all software packages.  Brand ecosystems make any change that is outside the boundary more difficult due to the investment in the tool, locking in business processes, and the collection of specific data and history. Just ask any programmer how much fun upgrading a package is if they have made changes to the base code. While configurable tools make change within the boundary of what is perceived as normal practice easy; any deviation outside that boundary is generally difficult.  For example, I have observed multiple organizations that have allowed teams (or departments) to define their own data structures for Agile tools. Data structures are used to define what the data that is tracked and reported. Allowing teams to operate without guidance often leads to teams using “user defined” fields differently (each with different usage and validation rules) across the organization making both sharing people between teams and implementing upgrades a horror story.
  2. Tools define the methods and frameworks. Tools which are typically a part of most brand ecosystems carry their own implied methodology or set of techniques. The methods embedded in the tools are generally proprietary making change difficult if not impossible. I use several Agile tools (and often recommend those tools to others); however, each tool represents a different instantiation of Agile or kanban.  Early in the life cycle of a movement, like Agile, competing brand ecosystems are very healthy. The competition acts as a powerful marketing tool to expand the market. As time progresses and market growth slows, brands shift from expanding the market to locking in customers and revenue streams ( an excellent example of capitalistic behavior).  This change in perspective shifts the intellectual underpinnings of the movement toward the brands and their economic needs from the needs of practitioners.
  3. Tools are put before the processes.  This consequence is a close cousin to the issue with brand defining the method and is a common occurrence in software development (broad definition) environments. Organizations adopt tools in a vain attempt to define how they work without really addressing how Agile (or any other method) is really supposed to work.  For example, I recently talked with a SPaMCAST listener whose company had purchased and adopted a very popular tool suite (one that I would have recommended). Once they had the “tool” training, they used that training to define how they would do Agile, rather than learning Agile and then defining how they would use the tool.  They used the steps built into the tool to define how they work.  They put tool deliverables ahead of customer deliverables. The organization was struggling with the value of using Agile. One example that of this issue shared by another reader of the blog was an implementation of user stories without involving, talking or reference to  . . . users.
  4. Messing with a stable process.  In a very similar vein, one of the classic brand ecosystem mistake occurs when organizations try to retrofit stable processes to a tool or brand suite even though they are delivering value and have good customer satisfaction.  This is sometimes a reflection of the “grass is always greener in your neighbor’s yard” factor, or sometimes a reflection of letting someone with a checkbook and organizational ADD go to a conference. If how work is done isn’t broken, think really hard about messing with it.

Brand ecosystems do not have to impede the Agile movement; they can actually make life easier. However, as the competition for users becomes more heated, stronger boundaries develop all sort of potential issues can arise.  To paraphrase Philip Lew on an upcoming Software Process and Measurement Cast, brands and tools won’t kill agile, people will kill agile with tools. We can buy into and use brand ecosystems, but we need to be very careful that we avoid getting locked.  Software development is not easy, once more than one team is involved the degree of complexity increases. Brand ecosystems become almost a requirement to deliver value. Unfortunately, they come with a cost that is often more than just money, part of the cost is the need to ensure flexibility.

Planned essays in Post Agile Age Arc include:

  1. Post Agile Age: The Movement Is Dead
  2. Post Agile Age: Drivers of the End of the Agile Movement and Method Lemmings
  3.  Proscriptive Norms
  4. A Brand Driven Ecosystems (Current)
  5. A Lack of Systems Thinking/Management
  6. The Age of Aquarius (Something Better is Beginning)

Categories: Process Management

How to Reward Agile Teams

Mike Cohn's Blog - Tue, 12/13/2016 - 16:00

I’ve been working with a company to revamp their bonus and incentive structure as part of the organization’s desire to become agile. No matter how well designed and executed an agile transition is, if incentives remain in place that encourage non-agile behavior, that’s how people will behave.

In “Succeeding with Agile,” I referred to this as organizational gravity. Unless enough of an organization’s culture is changed in becoming agile, organizational gravity pulls the organization right back to where it started.

Improperly aligned bonuses and incentives are some of the biggest sources of organizational gravity.

Incentives and Bonuses Are Different

Before looking at how we can create proper bonuses and incentives, let me clarify the difference between a bonus and an incentive.

An incentive is a reward given to an individual or team for achieving a stated goal. An incentive is offered in advance and is meant to motivate behavior in predictable ways. When my youngest daughter was little, I told her that if she cleaned her room by 3:00 p.m., I would take her to see a movie. That was an incentive.

In contrast, a bonus is not stated in advance. Rather it is announced and given at the time something is accomplished. Again using my youngest daughter as an example, when she came home from school with a great grade on a test I knew she’d studied hard for, I told her we’d celebrate that accomplishment by getting ice cream. That was a bonus.

Incentives and bonuses are both rewards with the key difference being that an incentive is announced in advance whereas a bonus is announced on the spot.

Some Troublesome Rewards

Bonuses and incentives can work against the goals of agile. For example, rewards that single out individual performers discourage teamwork. I’ve seen these in the form of “Programmer of the Year,” “Team Member of the Month,” “Most Valuable Contributor” and more.

Other types of rewards encourage suboptimizing behavior. Many of us have stories about testers who were rewarded based on the number of bugs they found. This type of reward led one tester I met to log over 200 entries into the defect tracking system for a single bug.

The bug was simply that a value was being improperly calculated and displayed on the screen. But the product ran on four operating systems (the current and prior versions of WIndows and Mac OS X), eight different browsers (the current and prior versions of four browsers), and was supported in seven different languages. So one bug was reported on Firefox v59 on Windows 8.1 in French. The same bug was reported on Safari 6.2 on MacOS 10.8 in English, and so on.

Bug reports like this wasted everyone’s time. But that tester sure looked productive in the “Bug Finder of the Month” contest.

How About Money?

Financial rewards are almost always a bad idea. Financial rewards are often introduced by a well-meaning boss who wants a team to make a particularly aggressive deadline. The boss will offer an enticing amount to the team if they can deliver by then.

So far, so good. But the problems arise on the next project. On that, the team may start on schedule, but they’ve been trained that if they get a little behind (or perhaps even only if they report themselves as a little behind), the boss will offer a bonus. This becomes a dangerous cycle.

Besides, financial rewards don’t tap into people’s intrinsic motivations. There’s absolutely nothing wrong with money. Most of us wouldn’t show up for work without at least some paycheck. But we’d like to tap into deeper motivations than the purely financial.

The Team That Taught Me About Financial Rewards

I learned a lot from a team many years ago to whom I gave a large financial bonus. This was two teams of 12 developers, and I gave them a bonus of $75,000, which would be more than $6,000 per person … if I split the bonus evenly.

And that was the trouble. I had allocated the bonus in the budget, so I had the money as a pool to give them. But when it came time to decide how I would give it to the team, I couldn’t decide.

Should I:

  • Give the same amount to each person? If I gave each person $6,000, that seemed unfair to those with high salaries and overly generous to others.
  • Give an amount proportionate to each person’s salary? This seemed the opposite.
  • Weigh the amounts by how many months the person had been on the project? It seemed unfair to give the same amount of money to a developer who joined the project a month ago as someone who had worked six months on it.
  • Give to the developers who had worked on this project but had been transferred off? It seemed unfair to leave them out, but if they weren’t there during the hardest period, did they deserve as much?

I couldn’t decide. I went back and forth on this. Some of the key people on the project knew I was planning this bonus and wrestling with this decision. They offered advice. But each person’s suggestions were always very aligned with what would reward them the most.

And so, I gave up.

I told the team I would give them $75,000 but it was their decision how to allocate the bonus.

I told them the issues I’d been struggling with and said that whatever they decided would be fine. But they had to all agree on the process they’d use and the allocation.

A week after I shifted the problem to them, we had a team meeting. They told me they could not find a way to distribute the bonus money. They argued about it. And they felt the money was interfering with the strong bonds they’d built as a team.

And they gave the money back. They decided they didn’t want it.

I don’t think I’d ever been more proud of--or surprised by a team.

We ultimately decided to spend some of the money on a nice out-of-town trip for everyone plus a significant other. The rest was returned to the budget.

And it was the last financial reward I’ve offered a team.

So How Should We Reward an Agile Team?

So how should we reward an agile team? I think the most important consideration is that rewards should encourage teamwork rather than individual performance. I favor rewards (both incentives and bonuses) that are given to everyone on the team.

This doesn’t mean there’s no role for individual rewards. I think those can be fine, but for individual rewards, I prefer to make them smaller, at least in relation to team rewards.

For example, I’ve worked with a few product owners who carry five-dollar bills and give them to team members who could quote the project’s elevator statement or three main goals when asked. No team member’s life was improved by $5. It was more the knowledge that they passed the test when asked. More than one of these team members pinned the $5 to their cubicle wall.

Similarly, a handwritten note can do wonders in this era of constant email deluge. Take the time to write a note every now and then thanking a team member for something special and specific they did.

One of my favorite rewards for a team is time. TIme is something that everyone seems constantly short of. I’ve rewarded a team with time a couple of different ways, which have been consistently well received. For example, you can offer a team an incentive of a week off if they meet some delivery milestone.

Or if a full week off is too much, offer the team a week (or a sprint) where all work is of their own choosing. They can refactor old code the product owner has been resistant to approving if they choose. They can experiment with new technologies. They can catch up on reading if they want. Whatever they choose is fine.

Another option is to give the team knowledge. If they achieve some goal, send everyone to a conference. If appropriate, everyone goes to the same conference. That’s especially good as you can include some fun time before or after. Or, if it’s better, allow each person to pick their own conference to attend some time during the year.

Or give everyone a book budget. (Yes, this is a financial reward, but it’s a little different.) Or a budget for online learning. Perhaps a Safari membership. Or even one of my video courses. But there are plenty of other options.

There is a role for incentives and bonuses on agile teams. But they need to be carefully designed to be consistent with agile’s emphasis on teamwork. But, done well, rewarding team members with incentives and bonuses can benefit the team and the organization.

What Do You Think?

How do you reward teams? Or how would you like to be rewarded as a team?

Quote of the Month December 2016

From the Editor of Methods & Tools - Mon, 12/12/2016 - 15:48
Experience shows that architecting is not something that’s performed once, early in a project. Rather, architecting is applied over the life of the project; the architecture is grown through the delivery of a series of incremental and iterative deliveries of executable software. At each delivery, the architecture becomes more complete and stable, which raises the […]

SPaMCAST 421 – Vanity Metrics, Unity of Purpose, Leadership

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 421 features our essay on vanity metrics.  Vanity metrics make people feel good, but are less useful for making decisions about the business.  The essay discusses how to recognize vanity metrics and the risks of falling prey to their allure.

We will also have columns form Steve Tendon with 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). Steve and I talked about Chapter 13.  Finally, Gene Hughson will anchor the cast with an entry from his Form Follows Function Blog.  Gene and I started talking about leadership patterns and anti-patterns.

Re-Read Saturday News

In this week’s re-read of The Five Dysfunctions of a Team  by Patrick Lencioni (Jossey-Bass, Copyright 2002, 33rd printing), we conclude Part Three with the sections titled the Last Stand, Flack, Heavy Lifting, and Rally. I suspect we have 3 or 4 weeks left before moving to the next book, BUT we still have a number of ideas to extract from this book.

If you are new to the re-read series buy a copy and  go back to week one and read along!

I have not heard any nay sayers on the idea of re-reading Carol Dweck’s Mindset next; however, just be to fair I am going to include a poll at the end to decide between Mindset, Thinking Fast and Slow (Daniel Kahneman) and Flow (Mihaly Csikszentmihalyi).  I would like your opinion!

Takeaways from this week include:

  • You are responsible for the atmosphere that you create.
  • Leaders and teams bear the consequence of not dealing with bad attitudes.
  • When someone leaves a team everyone will mourn to some extent.

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

Next SPaMCAST

The Software Process and Measurement Cast 422 will feature our interview with Phil Lew.  Phil and I talked about the topic of Agile risk management.  We explored how risk can be managed in Agile projects and the barriers to effective risk management.

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 421 - Vanity Metrics, Unity of Purpose, Leadership

Software Process and Measurement Cast - Sun, 12/11/2016 - 23:00

The Software Process and Measurement Cast 421 features our essay on vanity metrics.  Vanity metrics make people feel good, but are less useful for making decisions about the business.  The essay discusses how to recognize vanity metrics and the risks of falling prey to their allure.

We will also have columns form Steve Tendon with 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). Steve and I talked about Chapter 13.  Finally, Gene Hughson will anchor the cast with an entry from his Form Follows Function Blog.  Gene and I started talking about leadership patterns and antipatterns.

Re-Read Saturday News

In this week’s re-read of The Five Dysfunctions of a Team  by Patrick Lencioni (Jossey-Bass, Copyright 2002, 33rd printing), we conclude Part Three with the sections titled the Last Stand, Flack, Heavy Lifting, and Rally. I suspect we have 3 or 4 weeks left before moving to the next book, BUT we still have a number of ideas to extract from this book.

If you are new to the re-read series buy a copy and  go back to week one and read along!

I have not heard any nay sayers on the idea of re-reading Carol Dweck’s Mindset next; however, just be to fair I am going to include a poll at the end to decide between Mindset, Thinking Fast and Slow (Daniel Kahneman) and Flow (Mihaly Csikszentmihalyi).  I would like your opinion!

Takeaways from this week include:

  • You are responsible for the atmosphere that you create.
  • Leaders and teams bear the consequence of not dealing with bad attitudes.
  • When someone leaves a team everyone will mourn to some extent.

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

Next SPaMCAST

The Software Process and Measurement Cast 422 will feature our interview with Phil Lew.  Phil and I talked about the topic of Agile risk management.  We explored how risk can be managed in Agile projects and the barriers to effective risk management.

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

Microservices, not so much news after all?

Xebia Blog - Sun, 12/11/2016 - 18:07
A while ago at Xebia we tried to streamline our microservices effort. In a kick-off session, we got quite badly side tracked (as is often the case) by a meta discussion about what would be the appropriate context and process to develop microservices. After an hour of back-and-forth, we reached consensus that might be helpful

Five Dysfunctions of a Team, Patrick Lencioni: Re-Read Week 11

Five Dysfunctions of a Team

Five Dysfunctions of a Team

In this week’s re-read of The Five Dysfunctions of a Team  by Patrick Lencioni (Jossey-Bass, Copyright 2002, 33rd printing), we conclude Part Three with the sections titled the Last Stand, Flack, Heavy Lifting, and Rally. I suspect we have 3 or 4 weeks left before moving to the next book, BUT we still have a number of ideas to extract from this book.

If you are new to the re-read series buy a copy and  go back to week one and read along!

I have not heard any nay sayers on the idea of re-reading Carol Dweck’s Mindset next, however just be to fair I am going to include a poll at the end to decide between Mindset, Thinking Fast and Slow (Daniel Kahneman) and Flow (Mihaly Csikszentmihalyi).  I would like your opinion!

Last Stand

Instead of coming to terms with the situation, Mikey refused to resign and threatens a lawsuit if fired. Kathryn’s restated her position was that she didn’t have to quit, but unless she was willing to change (something she probably wasn’t interested in doing) she would have to leave. In chess this is classically known as a fork. The attacker presents his/her opponent with two possible outcomes (let’s say the loss of a queen or a castle) and the opponent gets to decide which position they wish to forfeit. For Kathryn, both options were an acceptable outcome. Note: in real life, if you are using this tactic it is important to ensure that there is not a third option or the outcome will less controlled. In this case, Mikey acquiesces and indicates she will resign if DecisionTech meets her set of demands. Kathryn said she would try to meet those demands even though they were within her purview, keeping Mikey off balance and holding on to the balance of power.Saying yes immediately in this type of negotiations probably isn’t a good idea. Even if you can say yes immediately don’t, let things sink in and then you can say yes. The Last Stand is an excellent primer on the use of power in negotiations.

The Mikey scenario in the book reinforces the idea that it is critical to be socially aware. Every individual will have an impact on a team, for good or for bad.  Regardless of whether someone is individually superlative, if they have to be part of a team it is critical that they support the team’s cultural and behavioral norms.

Flack

In this section Kathryn informs the team that Mikey is gone, and observes that even though Mikey had been a cancer on the team that her resignation is a downer.

Having been part of organizations that have had to shed personnel because they did not fit the team, I can validate Lencioni’s statement that generally no one enjoys the immediate aftermath of someone being fired or being pushed to resign. In the long run, it is often getting rid of someone that is bad for the team is better for the team, for the organization and sometimes even for the individual.

Heavy lifting

While the off-site, the proverbial show had to go on. The group wrestled with the loss of Mikey. Teams often mourn because no one understands how they will be impacted. This again, from my experience, is fairly common.  Kathryn used a story from early in her career to drive home the point that a bad fit can destroy a team and kill careers.  In the story Katheryn promoted a Mikey like person only to have the team fail to deliver, many people quit and Kathryn was fired.  The story made sure everyone in the room knew the consequences of not acting.  More importantly Kathryn used the story as a tool to tell everyone that she had removed the illness in the team to save the whole team.  Kathryn directly states she does not want to lose anyone else, sending a soothing message to those remaining.

Rally

Section three of the book concludes with the Rally.  When Mikey’s departure was announced to the organization there is more concern among the staff than anticipated.  Most of the angst is over tactical issues. The angst that the organization feels is more than offset by less bad behavior between teams and between the members of the “Staff” (remember that is what the executive team was once called when they focused only on day-to-day activities). Overall everyone in the in the organization recognized more unity of purpose.  The real business issues were being sorted out at the top of the organization rather than to be left to wrestle with by people without the power to make decisions.

Three key takeaways:

  1.      You are responsible for the atmosphere that you create.
  2.      Leaders and teams bear the consequence of not dealing with bad attitudes.
  3.      When someone leaves a team everyone will mourn to some extent.

Poll for the next book! Take Our Poll (function(d,c,j){if(!d.getElementById(j)){var pd=d.createElement(c),s;pd.id=j;pd.src='https://s1.wp.com/wp-content/mu-plugins/shortcodes/js/polldaddy-shortcode.js';s=d.getElementsByTagName(c)[0];s.parentNode.insertBefore(pd,s);} else if(typeof jQuery !=='undefined')jQuery(d.body).trigger('pd-script-load');}(document,'script','pd-polldaddy-loader'));

Previous Installments in the re-read of  The Five Dysfunctions of a Team by Patrick Lencioni:

Week 1 – Introduction through Observations

Week 2 – The Staff through the End Run

Week 3 – Drawing the Line though Pushing Back

Week 4 – Entering Danger though Rebound

Week 5 – Awareness through Goals

Week 6 – Deep Tissue through Exhibition

Week 7 – Film Noir through Application

Week 8 – On-site through Fireworks

Week 9 – Leaks through Plowing On

Week 10 – Accountability through The Talk


Categories: Process Management

Post-Agile Age: Proscriptive Norms

Tattoo artists are a profession that requires certification.

Tattoo artists are a profession that requires certification.

In a recent conversation on the Post-Agile Age with Ira Weinstein, Scrum master, architect and more, I pointed out that the end of Agile as movement did not mean that people would stop doing stand-ups, test driven development or even retrospectives, but rather the basis for adoption was no longer driven by the values and principles espoused by the Agile Manifesto. This change in the reason why people are adopting Agile changes the practices that get adopted and the value derived through Agile practices.  The discussion of a Post-Agile Age is not an esoteric exercise.  During our discussion, we examined the impact of the development of more and stronger proscriptive norms that define what is or more accurately what isn’t Agile.

Proscriptive norms describe or identify behavior that should not be performed. For example, developing a work breakdown structure with effort estimates and a project schedule would be branded as not agile based on typical proscriptive norms within the Agile community. As a point of reference, prescriptive norms are a set of rules that define behavior. Every Agile community has defined a set of behaviors that are inside the boundary and a set of rules that outside the boundary. For example, in a recent presentation, I have asked a group of Scrum masters to list a set of good and bad Scrum behaviors. And then asked the XP developers that were in the presentation to identify the practices they thought were outside of the practice of XP and whether they would be comfortable performing those activities. During the discussion, there were several practices both camps indicated they were not comfortable performing within their team.  While this was not a scientific survey, it illustrates that boundaries exist even in highly related communities.  As Agile has matured, boundaries have become more defined and more strongly defended. Certifications are the frontline of defining boundaries for behavior.  Nearly every organization and method has one or more certification. Offhand I can name six different Scrum master certification and a huge number of other roles in Agile.

Prima facie, certifications are not good or bad.  My son-in-law, a tattoo artist, (I can probably get you a deal) is certified. He has a set of norms for good practice that provides a boundary for what he can and can’t do which include rules on sterilization and handling blood. The pilot of my recent airline flight has a license (an assumption on my part), a form of certification, that provides boundaries for her behavior and defines things they are not supposed to do (such as drinking 24 hours before the flight). Stringent boundaries serve an important purpose in both these professions. These stringent boundaries are not appropriate for all professions.  Certification ensures everyone knows what the boundaries are and establish consequences for violating those boundaries.

In my conversation with Ira, he suggested that certifications were important tools for ensuring that new entrants to the IT industry understood the basics of their profession.  Further, he posited that when new entrants had enough experience they should switch into an inspect and adapt mode to modify how they work. Point taken, establishing a common basis of knowledge is great; however we need to determine whether the unintended consequences of hardening boundaries are an acceptable side effect of syncing knowledge bases. Additionally, I do not know a certification that suggests experimenting with processes and techniques outside their core techniques and processes (I am excluding process improvement frameworks such as lean six sigma). One of the basic assumptions of the Agile movement is that teams use an empirical process (inspect, adapt based on transparency).

Scrum and XP are empirical processes.  Agile practitioners use feedback to adapt how theysz work.  In a typical end of iteration retrospective, teams are challenged to find one way they can improve how they work.  Agile expects teams to continuously perform small, low-risk experiments to hone how they are doing their jobs. Changes to how a team work are not meant to be bounded by the requirements of a certification.

Certifications are not evil. However, they do create boundaries that slow down change. Boundaries also constrain the evolution of the process.  Neither of these consequences, in the long run, are good.  The only long term good of hardening the boundaries around different types of Agile that the hardening is a flag that we should begin to search the horizon for the next movement.   During a keynote, at the Scrum Gathering in 2014 (ish), Ken Schwaber described things like user stories as barnacles on Scrum.  Certifications harden boundaries which reduce potential innovation.  I am not sure if I can conceive of Agile without innovations, like user stories or my personal favorite technique Scrumban. If overly defined proscriptive norms had existed early in Agile’s lifecycle then they might not exist.   

Planned essays in Post Agile Age Arc include:

  1. Post Agile Age: The Movement Is Dead
  2. Post Agile Age: Drivers of the End of the Agile Movement and Method Lemmings
  3. Proscriptive Norms (Current)
  4. A Brand Driven Eco
  5. A Lack of Systems Thinking/Management
  6. The Age of Aquarius (Something Better is Beginning)

Categories: Process Management

The Impostor Software Developer Syndrome

From the Editor of Methods & Tools - Wed, 12/07/2016 - 17:50
Did you ever feel like a fraud as a software developer? Have the feeling that at some point, someone is going to find out that you really don’t belong where you are? That you are not as smart as other people think? You are not alone with this; many high-achieving people suffer from the imposter […]

Post-Agile Age: Drivers of the End of the Agile Movement and Method Lemmings

Follow the leader?

Follow the leader?

I had a conversation with Mauricio Aguiar of ti Metricas earlier this week discussing the cycle of change in software development.  In the end, there is only one absolute.  The person paying the bill wants value, always more value.  The Agile movement is just the current iteration cycle in the search for the tools to deliver more value. The movement marked and driven by the Agile Manifesto has had a great run.  Agile as a movement provided a new framework to think about how work should or could be approached. However, the movement driven by values and principles has faded to be replaced by a focus on frameworks and techniques.  This new focus is neither good nor bad, but rather an evolution and step towards the next big thing. There are four major factors that contributed to the end of Agile as movement:

  1. Method Lemmings – Just doing Agile, and therefore often doing Agile inappropriately.
  2. Proscriptive Norms – Defining boundaries around methods that reduce flexibility.
  3. A Brand Driven Eco-Systems – Splintering of schools of thought driven by economic competition. 
  4. A Lack of Systems Thinking/Management – A resurgence of managing people and steps rather than taking a systems view.

Every major trend in IT has been impacted these drivers.  Interestingly, they have tended to appear in the same order as each new movement has appeared and then evolved. 

Method Lemmings:

The idea of method lemmings was introduced to me by Larry Cooper, creator and force behind the Agility Series (interviewed on SPaMCAST 418).  Larry used to the term ‘method lemmings’ to describe the group of practitioners that have a need to be seen to be doing what the “cool” people are doing. Stated in a little less inflammatory manner, method lemmings are those in the classic product acceptance life cycle that in the early and late majority phase of the cycle are doing Agile because everyone else is doing Agile.

product-adoption-lifecycle

Any product or movement will ride the product adoption lifecycle.  The slope of the ascent (and probably the decent) will be a reflection of the degree the product or idea that catches the imagination of its target market.  The bigger the frenzy the more people that jump on the bandwagon because of the coolness factor.  These are the people Larry classified as method lemmings.  In Agile there has been a passionate discussion about the difference between doing Agile and being Agile. Those that are Agile embrace the principles and then fit practices to the work; those that do are more apt to apply techniques in rote or inappropriately.  For example, this morning a friend who owns a medium-sized consulting firm approached several firms to handle their standard payroll. We end discussed the bid from two the firms.  Both were equally prominent in the marketplace and had many years in the industry. One firm suggested that since they used Agile they would create a backlog for the conversion but could not commit to a price or date for the conversion. Another that also used Agile stated that a payroll conversion was a common project and that because they used Agile and Lean techniques they could quote a price and commit to being ready for a specific date.  I would suggest that the later was being Agiler (if that really is a word) than the former although both were probably using similar techniques. The later firm got the business because the first organization’s approach seemed to put techniques in front of delivering value. In this case, at the very least, just doing Agile techniques without understanding the principles, which are value focused,  did not appear to add value to the customer. Just following the pack over the cliff leads to problems and fails to deliver value to customers, which weakens the value of adopting Agile!

Planned essays in Post Agile Age Arc include:

  1. Post Agile Age: The Movement Is Dead
  2. Post Agile Age: Drivers of the End of the Agile Movement and Method Lemmings (Current)
  3. Proscriptive Norms
  4. A Brand Driven Eco
  5. A Lack of Systems Thinking/Management
  6. The Age of Aquarius (Something Better is Beginning)

Categories: Process Management

SPaMCAST 420 – John Hunter, Building Organizational Capability

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 420 features our interview with John Hunter.  John is a SPaMCAST alumni; John first appeared on SPaMCAST 226 to talk about why management matters.  In this podcast John returns to discuss building capability in the organization and  understanding the impact of  variation.  We also talked Deming and why people tack the word improvement on almost anything!   

John’s Bio

John Hunter has served as an information technology program manager for the Office of Secretary of Defense Quality Management Office, the White House Military Office and the American Society for Engineering Education.

In 2013, he published his first book – Management Matters: Building Enterprise Capability.

John created and operates one of the first, and still one of the most popular, management resources on the internet.  He continues to aid managers in their efforts to improve their organizations with an emphasis on software development and leveraging the internet.  His blog is widely recognized as a valuable resource for leaders and managers with a focus on improving the practice of management in organizations.

Re-Read Saturday News

In this week’s re-read of The Five Dysfunctions of a Team  by Patrick Lencioni (Jossey-Bass, Copyright 2002, 33rd printing), we tackle the sections titled Accountability, Individual Contributor, and The Talk.  We are getting close to the end of the novel portion of the book but over the next few weeks, we have a number of ideas to extract from the book before we review the model.

(Remember to buy a copy and read along.)  We are well over halfway through this book and I am considering re-reading Carol Dweck’s Mindset next.  What are your thoughts?

Takeaways from this week include:

  • Team members hold other team members accountable.        
  • Be aware of how you affect the people around you or suffer the consequences!
  • Try to step back and reduce the stress when confronted by tough negotiations.

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

Next SPaMCAST

The Software Process and Measurement Cast 421 will feature our essay on vanity metrics.  Vanity metrics make people feel good, but are less useful for making decisions about the business.  The essay discusses how to recognize vanity metrics and the risks of falling prey to their allure.

We will also have columns form Steve Tendon with 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).   Finally, Gene Hughson will anchor the cast with an entry from his Form Follows Function Blog.  

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 420 - John Hunter, Building Organizational Capability

Software Process and Measurement Cast - Sun, 12/04/2016 - 23:00

The Software Process and Measurement Cast 420 features our interview with John Hunter.  John is a SPaMCAST alumni; John first appeared on SPaMCAST 226 to talk about why management matters.  In this podcast John returns to discuss building capability in the organization and  understanding the impact of  variation.  We also talked Deming and why people tack the word improvement on almost anything!   

John’s Bio

John Hunter has served as an information technology program manager for the Office of Secretary of Defense Quality Management Office, the White House Military Office and the American Society for Engineering Education.

In 2013, he published his first book - Management Matters: Building Enterprise Capability.

John created and operates one of the first, and still one of the most popular, management resources on the internet.  He continues to aid managers in their efforts to improve their organizations with an emphasis on software development and leveraging the internet.  His blog is widely recognized as a valuable resource for leaders and managers with a focus on improving the practice of management in organizations.

Re-Read Saturday News

In this week’s re-read of The Five Dysfunctions of a Team  by Patrick Lencioni (Jossey-Bass, Copyright 2002, 33rd printing), we tackle the sections titled Accountability, Individual Contributor, and The Talk.  We are getting close to the end of the novel portion of the book but over the next few weeks, we have a number of ideas to extract from the book before we review the model.

(Remember to buy a copy and read along.)  We are well over halfway through this book and I am considering re-reading Carol Dweck’s Mindset next.  What are your thoughts?

Takeaways from this week include:

  • Team members hold other team members accountable.        
  • Be aware of how you affect the people around you or suffer the consequences!
  • Try to step back and reduce the stress when confronted by tough negotiations.

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

Next SPaMCAST

The Software Process and Measurement Cast 421 will feature our essay on vanity metrics.  Vanity metrics make people feel good, but are less useful for making decisions about the business.  The essay discusses how to recognize vanity metrics and the risks of falling prey to their allure.

We will also have columns form Steve Tendon with 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).   Finally, Gene Hughson will anchor the cast with an entry from his Form Follows Function Blog.  

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