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

Mind Mapping: An Introduction

A mind map on mind maps

A mind map on mind maps

A number of years ago I was the chair of the IFPUG Conference Committee.  Finding a keynote speaker that had the gravitas to fill seats (on a budget) and that would challenge the audience was a difficult chore. I had been pursuing Ed Yourdon for a few years, however he was too expensive. In 2002 my annual begging and the weak conference market convinced Ed to give IFPUG a break so we could afford him. A few weeks before the conference Ed announced that he would not be providing a set of PowerPoint slides, but rather would be using something called a mind map. I think I considered calling in sick to the conference I was so worried by the approach.  In retrospect Ed’s use of mind mapping represented one of those life-changing moments.

Mind mapping is a technique for mapping information using color, pictures, symbols and most importantly a branching structure emanating from a central concept. The technique and term mind mapping were popularized by a Tony Buzan in 1974. Mind mapping includes and leverages ideas and techniques from other problem-solving techniques and concepts such as radiant thinking and general semantics.

Mind mapping provides a tool to organize thought in a non-linear manner that allows the mind mapper to see the whole picture at once and the relationships between the components of the map. According to Buzan outlining, one of the most popular technique for gathering and organizing information, forces users into a top-to-bottom, left-to-right view of the data. Outlining by its nature can impart a deterministic view of the topic being studied (a form of cognitive bias). The popular psychology promoted by Buzan suggests that mind mapping by using words, color, pictures and symbols engages more parts of the mind. In Learning Styles and Teams we discussed the Seven Learning Styles model. Each style absorbs and processes information differently, but while everyone has a predominant style of learning they also are influenced by other styles. The use multiple techniques to gather, organize and convey information engages multiple learning styles therefore we would expect mind mapping to be useful to a broad range of learners.

Mind maps have a few drawbacks. I have observed that some people are (or are trained to be) very linear thinkers. The non-linear approach of a mind map does not work well for linear thinkers.  Note these types of thinkers will also generally have trouble with techniques like affinity diagramming. If you are linear thinker, feel free to experiment with mind mapping but remember that you always have the classic outlining techniques to fall back upon. A second drawback is that since when you draw a mind map the map is a reflection of how you think. In many cases this means the resulting map will be difficult for others to interpret. If a group is going to use the mind map to plan work (one use for a mind map) I strongly suggest building the map as a group effort.

The branching, tree-like structure of a mind map presents a central concept at the center of the map with major topics radiating from that topic. The map continues to branch out to the level of granularity that is important to the person drawing the map. A mind map allows the user to organize and visualize information so it can be consumed both at a big picture level and then drill down to a granular level in a manner that exposes relationships and engages the senses.

 


Categories: Process Management

Scrum Repair Guide Giveaway

Mike Cohn's Blog - Mon, 04/14/2014 - 03:11

Our newest venture, Front Row Agile, launched last week to bring online agile and Scrum training from the industry's leading educators to people all over the world.

To celebrate its launch, we're running a raffle to give away my newest online training, the "Scrum Repair Guide," to one winner. 

Entering the contest is simple. Head on over to the contest page at Front Row Agile to learn more. The contest starts today and ends at midnight Pacific Time this Thursday, April 17.

As part of the giveaway, I'll be donating $1 for every person who participates to the non-profit organization, Best Friends, which provides alternatives to euthanizing animals housed in shelters. 

 

 

 

 

 

 

 

 

 

 

Good luck!

SPaMCAST 285 – FAQ of a Consulting Kind, The Software Sensei, Failure Mode and Effects Analysis

www.spamcast.net

http://www.spamcast.net

Listen to the Software Process and Measurement Cast 285. SPaMCAST 285 features a compilation of frequently asked questions of a consulting kind.  Working as a traveling consultant, podcaster and blogger provides me with a fabulous mix of experiences. Meeting new people and getting to participate in a wide range of real life experiences is mind expanding and invigorating. Many of the questions that I have been asked during a client engagement, on the blog or in response to a podcast have similar themes. Since most of the answers were provided in one-on-one interactions I have compiled a few of the questions to share. If these questions spark more questions I promise to circle back and add to the FAQ list!

The SPaMCAST 285 also features Kim Pries’s column, The Software Sensei. In this edition, Kim tackles the concept of failure mode and effects.

Get in touch with us anytime or leave a comment here on the blog. Help support the SPaMCAST by reviewing and rating it on iTunes. It helps people find the cast. Like us on Facebook while you’re at it.

Next week we will feature an interview with Brian Wernham author or Agile Project Management for Government. Combining Agile and government used in the same phrase does not have to be an oxymoron.

Upcoming Events

StarEast

I will be speaking at the StarEast Conference May 4th – 9th in Orlando, Florida.  I will be presenting a talk titled, The Impact of Cognitive Biases on Test and Project Teams. Follow the link for more information on StarEast. ALSO I HAVE A DISCOUNT CODE
. Email me at spamcastinfo@gmail.com or call 440.668.5717 for the code.

ITMPI Webinar!

On June 3 I will be presenting the webinar titled “Rescuing a Troubled Project With Agile.” The webinar will demonstrate how Agile can be used to rescue troubled projects.  Your will learn how to recognize that a project is in trouble and how the discipline, focus, and transparency of Agile can promote recovery. Register now!

I look forward to seeing all SPaMCAST readers and listeners at all of these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

 

Shameless Ad for my book!

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

Available in English and Chinese.

 

 


Categories: Process Management

SPaMCAST 285 – FAQ of a Consulting Kind, The Software Sensei, Failure Mode and Effects Analysis

Software Process and Measurement Cast - Sun, 04/13/2014 - 22:00

Listen to the Software Process and Measurement Cast 285. SPaMCAST 285 features a compilation of frequently asked questions of a consulting kind.  Working as a traveling consultant, podcaster and blogger provides me with a fabulous mix of experiences. Meeting new people and getting to participate in a wide range of real life experiences is mind expanding and invigorating. Many of the questions that I have been asked during a client engagement, on the blog or in response to a podcast have similar themes. Since most of the answers were provided in one-on-one interactions I have compiled a few of the questions to share. If these questions spark more questions I promise to circle back and add to the FAQ list!

The SPaMCAST 285 also features Kim Pries’s column, The Software Sensei. In this edition, Kim tackles the concept of failure mode and effects.

Get in touch with us anytime or leave a comment here on the blog. Help support the SPaMCAST by reviewing and rating it on iTunes. It helps people find the cast. Like us on Facebook while you’re at it.

Next week we will feature an interview with Brian Wernham author or Agile Project Management for Government. Combining Agile and government used in the same phrase does not have to be an oxymoron.

Upcoming Events

StarEast
I will be speaking at the StarEast Conference May 4th – 9th in Orlando, Florida.  I will be presenting a talk titled, The Impact of Cognitive Biases on Test and Project Teams. Follow the link for more information on StarEast. ALSO I HAVE A DISCOUNT CODE…. Email me at spamcastinfo@gmail.com or call 440.668.5717 for the code.

ITMPI Webinar!
On June 3 I will be presenting the webinar titled “Rescuing a Troubled Project With Agile.” The webinar will demonstrate how Agile can be used to rescue troubled projects.  Your will learn how to recognize that a project is in trouble and how the discipline, focus, and transparency of Agile can promote recovery. Register now!

I look forward to seeing all SPaMCAST readers and listeners at all of these great events! 

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI's mission is to pull together the expertise and educational efforts of the world's leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

 Shameless Ad for my book!

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

Available in English and Chinese.

Categories: Process Management

Spring Cleaning

Spring flowers

Spring flowers

In my home it is traditional every spring to thoroughly clean our house, yard and even our office.  Spring cleaning is different than a normal cleaning.  Everything gets touched, sorted and perhaps even thrown away. When we are done it always amazes me to step back and see the stuff that has accumulated since our last spring cleaning that is no longer needed. The same spring-cleaning concept can be applied to the processes that you use at work.

  1. Convene a small team. Consider using a Three Amigos-like process consisting of a developer, tester and process or business analyst. The small team will reduce the time needed to come to aconsensus and the inclusion of multiple disciplines will help make sure that important steps don’t get “cleaned up.”
  2. Map your actual processes. A simple process map showing steps with their inputs and outputs will be useful for focusing the spring cleaning on what is actually being done rather what is supposed to be happening.
  3. Review your actual process against the organizational standard or what every thinks ought to be happening.
    1. Identify steps that have been added to the process. Ask if the added steps can be removed. In many cases, process steps are added to prevent a specific mistake or oversight. I recently saw a process with a weekly budget review signoff because in an earlier release the team had gone over budget. The step in process added two additional hours of overhead to collect and validate signatures (the data already existed).
    2. Review each step in the process to determine whether there are simpler ways to accomplish the same result. In the example of the weekly budget review, we removed the step and put a simple budget burn down chart on the wall in the team room, which took approximately five minutes to update every week.
  4. Review the process change recommendations with the rest of the project team. I like convening a lunch session to review the changes and to share a common meal.
  5. Implement the process changes based on the review and monitor the results.
  6. Calculate and monitor the project’s burden rate. The burden rate is a simple metric that is the ratio of testing, review, sign-off and management to total time.  The burden rate represents the overhead being expended to manage the project and to ensure quality. If you were to be able to construct a perfect engineering process the burden rate would be zero, however perfect is not possible. Spring cleaning should reduce the burden rate. I recommend reviewing the burden rate during a retrospective periodically so that overhead does not creep back into the process.

Spring cleaning is a tradition in many of the colder climates. When the days grow warmer and longer all the extra stuff that has accumulated over the winter becomes obvious and a bit oppressive. Cleaning out what isn’t needed lifts the spirits; process spring cleaning serves the same purpose. Get rid of steps that don’t add value and simplify how you work.  A process spring cleaning will lift your team’s spirits and help them deliver more value. Spring cleaning is part of a virtuous cycle.


Categories: Process Management

The Final Factors in the Success of Agile Implementations

 

Agile like cooking is about  people.

Agile like cooking is about people.

Over the past few weeks I have been asking friends and colleagues to formally answer the following question:

What are the top reasons you think an organization succeeds in implementing Agile?

We have already covered the top six reasons organizations succeed with Agile.

  1. Senior Management
  2. Engagement, Early Feedback (Tied)
  3. Trust, Adaptable Culture, Coaching (Tied)

The folks that participated in this survey are from a highly experienced cohort of process improvement personnel, testers or developers. Completing the top eleven success factors in the survey are the areas of process discipline, team size, capable people and appropriate training.

Process discipline reflects the team’s capability to follow and improve the organization’s standard processes. For example, if Scrum were the standard Agile project management process you would expect that the team would follow standard practices of Scrum. The team would use retrospectives to tailor that process based on data gathered through experience within the limits the organization established. Process discipline is required for a group of people to work together to solve a common problem without tripping over themselves. Without process discipline it will be difficult for team members to predict how other team members will behave requiring a need to built in contingency.

Team size influences efficiency and effectiveness of Agile techniques. Agile teams typically have five to nine members. Team size is the sum of the entire core team; product owner, Scrum Master and the development members. Many of the collaborative techniques typically used in Agile don’t work well when team sizes expand.  For example, large teams tend to have difficulty completing standup meetings in a reasonable period of time, which causes participants to become bored and inattentive. When team members start to checkout, command and control management techniques are generally substituted for Agile techniques and principles.

Capable people are required to apply Agile processes. This was the most obvious success factor and probably the one that is least specific to Agile. Capable people are a requirement for any type of work. The combination of personal capability and engagement, an earlier success factor, both are required for Agile to prosper in an organization.

Appropriate training is required to apply Agile. Training should be provided not only to the core team, but to all of the stakeholders that will be impacted by the team’s new behavior. Training generally needs to be nuanced. Business stakeholders will have different training and knowledge needs than IT support teams. On a cautionary note, many organizations confuse presentations with training. Training for Agile needs to embrace the adult learning concepts that include an explanation and hands on practice before trainees are asked to use the material. In order to be most effective, training should be deployed just prior to time of need (just-in-time training).

Success implementing and using Agile requires that teams keep their eye on the ball both in terms of using the process as well as on delivering value. Process discipline, team size, capable people and training are all revolve around people and it bears repeating that people are center of Agile world.


Categories: Process Management

Checklist for Process Improvement Success

I spend lots of time in airports.

I spend lots of time in airports.

I get around.  Once upon a time in my life that might have been an epithet but now reflects a wide exposure to what works, doesn’t work and what is clearly a cop out.  I suggest that there are five requirements for a successful process improvement program or five attributes that give a program a chance of success.  They are:

  1. The best and brightest
  2. Understanding of change management
  3. The wish to change
  4. A commitment to change in dollars and cents
  5. Recognition that implementation matters
The best change programs are staffed by people that have a solid track record of success both technically and in business terms. The right candidates will have a high follow-ability quotient.  Follow-ability is combination of a number of attributes including optimism, successful, collaborative, vision and leadership. Change management is a structured approach to shifting/transitioning individuals, teams, and organizations from a current state to a desired future state.  It requires planning for selling and promoting ideas, then supporting the nascent changes until that have achieved critical mass.  Make sure your process improvement group has someone trained in change management.   Skills will include sales, promotion, branding, communication and organizational politics. I have observed many change programs that were created to check a box.  There was no real impetuous within the organization to change.  The organization must want to change; to become something different or the best a change program can do is to put lipstick on a pig. Having a commitment to change in dollars and cents is critical.  I suggest funding the process improvement program by having each of the affected groups contribute the needed budget. The word contribute means that they can choose not to renew funding if they do not get what they need. The funding linkage ensures that the funding groups stay involved and at the same time makes sure the process improvement team recognizes their customer. Finally the recognition that implementation matters is the capstone.  Process changes, unlike spaghetti, cannot be tossed against the wall to determine if it is done.  How a process change is implemented will determine whether it sticks.  An implementation plan that integrates with the organization change management plan is part of the price of admission for a successful change
Categories: Process Management

Trust, Adaptable Culture and Coaches and the Success of Agile Implementation

Adaptable culture, not adaptable hair...

Adaptable culture, not adaptable hair…

So far we have discussed three of the top factors for successful Agile implementations:

  1. Senior Management
  2. (Tied) Engagement and Early Feedback

Tied for fourth place in the list of success factors are trust, adaptable culture and coaching.

Trust was one of surprises on the list. Trust, in this situation, means that all of the players needed to deliver value including the team, stakeholders and management should exhibit predictable behavior. From the team’s perspective there needs to be trust that they won’t be held to other process standards to judge how they deliver if they adopt Agile processes. From a stakeholder and management perspective there needs to be trust that a team will live up to the commitments they make.

An adaptable culture reflects an organization’s ability to make and accept change.  I had expected this to be higher on the list.  Implementing Agile generally requires that an organization makes a substantial change to how people are managed and how work is delivered.  Those changes typically impact not only the project team, but also the business departments served by the project. Organizations that do not adopt to change well rarely make a jump into Agile painlessly. Organizations that have problems adapting will need to spend significantly more effort on organizational change management.

Coaches help teams, stakeholders and other leaders within an organization learn how to be Agile. Being Agile requires some combination of knowing specific techniques and embracing a set of organizational principles. Even in more mature Agile organizations, coaches bring new ideas to the table, different perspectives and a shot of energy. That shot of energy is important to implementing Agile and then for holding on to those new behaviors until they become muscle memory.

Change in organizations is rarely easy. Those being asked to change very rarely perceive change being for the better, which makes trust very difficult. Adopting Agile requires building trust between teams, the business and IT management and vice versa. Coaching is a powerful tool to help even adaptable organizations build trust and embrace Agile as a mechanism to deliver value and as a set of principles for managing work.


Categories: Process Management

Engagement and Early Feedback and the Success of Agile Implementation

Engagement and feedback are interrelated like the bricks in the aqueduct.

Engagement and feedback are interrelated like the bricks in the aqueduct.

In Senior Management and the Success of Agile Implementation,I described the results of a survey of experienced process improvement personnel, testers or developers felt contribute to a successful Agile implementation. Tied for second place in the survey were team engagement and generating early feedback. These two concepts are curiously inter-related.

Team engagement is a reflection of motivated and capable individuals working together.  Agile provides teams with the tools to instill unity of purpose. Working with the business on a continuous basis provides the team a clear understanding of the project’s purpose. Short iterations provide the team with a sense of progress. Self-management and retrospectives provide teams with a degree of control over how they tackle impediments.  Finally, the end-of-sprint demonstrations provide early feedback. Feedback helps reinforce the team’s sense of purpose, which reinforces motivation.

Early feedback was noted in the survey as often as team engagement. In classic software development projects, the project would progress from requirements through analysis, design, coding and testing before customers would see functional code.  Progress in these methods is conveyed through process documents (e.g. requirements documents) and status reports. On the other hand, one of the most important principles of Agile states:

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Delivering functional software provides all of the project’s stakeholders with explicit proof of progress and provides stakeholders with a chance to provide feedback based on code they can execute. Early feedback increases stakeholder engagement and satisfaction, which also helps to motivate the team. As importantly, since stakeholders see incremental progress, any required course corrections are also incremental.  Incremental course corrections help to ensure that when the project is complete that most value possible has been delivered.

Team engagement and early feedback are both important to successful Agile implementations. Interestingly, both concepts are inter-twined. Feedback helps to generate engagement and motivation. As one of the respondents to the survey stated, “Agile succeeds when it instills ‘unity of purpose’ and builds a ‘community of trust’ within an organization.” Team engagement and early feedback provides a platform for Agile success.


Categories: Process Management

Senior Management and the Success of Agile Implementation

Senior leadership needs to lead by example.

Senior leadership needs to lead by example.

Over the past few weeks I have been asking friends and colleagues to formally answer the following question:

What are the top reasons you think an organization succeeds in implementing Agile?

The group that participated in this survey are from a highly experienced cohort of process improvement personnel, testers or developers. Not all of the respondents were sure Agile and success belonged in the same sentence (more on that later in the week). There was a rich range of answers, however after the first dozen responses a consensus formed. Today I would like to explore the most important success factor as reported in this survey: senior leadership support.

Senior management support was the most often mentioned factor influencing Agile Success. By far one of the significant nuances in the senior management support was exhibiting a true understanding of Agile. In particular, senior managers must understand what Agile really is rather than falling prey to buzzword bingo.  One of the respondents suggested that, “I feel most senior leaders that I have dealt with don’t have a full understanding of what is needed and it trickles down to the rest of the organization.” Senior leaders need to walk the talk when it comes to Agile, if they expect to implement Agile successfully.  They need to prove to both team members and middle managers that they understand how Agile impacts the flow of work through a sprint and that Agile teams are expected to self-organize. Senior leaders will help pull the transition to Agile forward by asking questions that elicit proof that teams are acting Agile.  For example, asking to see team’s burn down chart rather than report-based status reporting sends a strong message that leads behavior.

In many organizations, following the process is as important as the outcome of any specific project. This is based on the presumption that precisely following the process foreshadows success. In the role of process champion, senior leaders own one of the more significant barriers to change. Senior leadership needs to incent teams to try new processes such as Scrum. Senior managers need to understand that Agile frameworks are scaffolds that that teams that need to be tailored to fit project needs and requirements. Providing incentive for teams to experiment will create an environment of flexibility so that teams can decide how address impediments as soon as they are encountered.

Teams need support from senior leadership to allow innovation or Agile implementations will fail. Support for Agile innovation derives from the expectations of senior management that teams will use Agile techniques.  These expectations need to part of the annual goals and objectives and be in evidence in the questions that leaders ask of middle managers and project teams. The power of asking for questions that require that teams prove they are using Agile is a VERY power evidence of a senior leader’s expectations.


Categories: Process Management

Announcing FrontRowAgile.com for Video Training

Mike Cohn's Blog - Mon, 04/07/2014 - 22:14

I’m happy to announce the release of a new website, FrontRowAgile.com. FrontRowAgile.com will provide the highest quality video training on agile and Scrum.

The site launches with two courses from me and with courses from others soon to follow. In addition to hosting all my current and upcoming video courses, FrontRowAgile.com will soon feature:

  • Ken Rubin on Agile Portfolio Management
  • Ilan Goldstein on Scrum Shortcuts: Agile Tactics, Tools and Tips
  • Mitch Lacey on The Scrum Field Guide Online and Scrum for Managers
  • Pete Deemer on Distributed Scrum Primer and The Manager and Scrum

Currently, FrontRowAgile.com hosts my Agile Estimating and Planning video course plus a new course I’m happy to announce: The Scrum Repair Guide.

The Scrum Repair Guide will help you overcome some of the most common and difficult problems that ScrumMasters and their teams face.

Featuring 36 videos split into short, easily watched segments, each video addresses one topic. Watch them all or watch just the ones you’re interested in. With the same number of Emmy Award nominations as Season 8 of Game of Thrones (none so far), you’re sure to find this course informative and entertaining.

The Agile Estimating and Planning course has been a favorite since it was published on the Mountain Goat Software site. It is now available exclusively on www.FrontRowAgile.com.

In it you will find advice on sprint planning; release planning; story points vs. ideal time; fixed-date, fixed-scope, and fixed-price plans; and estimating on multi-team projects.

 

[Note: If you own a license to Agile Estimating and Planning on the Mountain Goat site, please continue logging in here and watching the course as you have been. We have plans to migrate all Mountain Goat Software video course owners to Front Row Agile as soon as we can.]

Looking to earn PDUs toward your PMI-ACP or PMP credentials? Or pursuing a Certified Scrum Professional (CSP) designation? These courses each earn you four PDUs and SEUs.

Additionally, each course will earn you a valuable certificate of completion and badges you can share on your own website, resume, or social media profiles.

 

 

 

 

 

 

 

 

 

And there’s more good news: With the move to Front Row Agile, all streaming licenses are being moved from six-month licenses to permanent licenses. That’s right—you’ll be able to watch these videos long after Doctor Who goes off the air.

And to celebrate, I’ve cut the price of Agile Estimating and Planning licenses in half. It used to be $200 for a six-month streaming license. Now it’s $100 for a permanent streaming license. The Scrum Repair Guide is available at the same price. Each of these courses offers well over 3 hours of video you can watch over and over.

If you want to watch without an Internet connection, download licenses are still available for each course. Quantity discounts are available and we have an innovative approach to company (site) licenses—email us at info@frontfrowagile and we’ll tell you more.

FrontRowAgile.com is committed to becoming the leading provider of video-based training on agile and Scrum. Sample videos from each course are available on the site.

Press Inquiries:

If you are interested in publishing a review of FrontRowAgile.com or of either course, please email us for one of a limited number of promotional licenses we are making available. Let us know which course you’re interested in reviewing and a link to where you would publish the review.

Announcing FrontRowAgile.com for Video Training

Mike Cohn's Blog - Mon, 04/07/2014 - 22:14

I’m happy to announce the release of a new website, FrontRowAgile.com. FrontRowAgile.com will provide the highest quality video training on agile and Scrum.

The site launches with two courses from me and with courses from others soon to follow. In addition to hosting all my current and upcoming video courses, FrontRowAgile.com will soon feature:

  • Ken Rubin on Agile Portfolio Management
  • Ilan Goldstein on Scrum Shortcuts: Agile Tactics, Tools and Tips
  • Mitch Lacey on The Scrum Field Guide Online and Scrum for Managers
  • Pete Deemer on Distributed Scrum Primer and The Manager and Scrum

Currently, FrontRowAgile.com hosts my Agile Estimating and Planning video course plus a new course I’m happy to announce: The Scrum Repair Guide.

The Scrum Repair Guide will help you overcome some of the most common and difficult problems that ScrumMasters and their teams face.

Featuring 36 videos split into short, easily watched segments, each video addresses one topic. Watch them all or watch just the ones you’re interested in. With the same number of Emmy Award nominations as Season 8 of Game of Thrones (none so far), you’re sure to find this course informative and entertaining.

The Agile Estimating and Planning course has been a favorite since it was published on the Mountain Goat Software site. It is now available exclusively on www.FrontRowAgile.com.

In it you will find advice on sprint planning; release planning; story points vs. ideal time; fixed-date, fixed-scope, and fixed-price plans; and estimating on multi-team projects.

 

[Note: If you own a license to Agile Estimating and Planning on the Mountain Goat site, please continue logging in here and watching the course as you have been. We have plans to migrate all Mountain Goat Software video course owners to Front Row Agile as soon as we can.]

Looking to earn PDUs toward your PMI-ACP or PMP credentials? Or pursuing a Certified Scrum Professional (CSP) designation? These courses each earn you four PDUs and SEUs.

Additionally, each course will earn you a valuable certificate of completion and badges you can share on your own website, resume, or social media profiles.

 

 

 

 

 

 

 

 

 

And there’s more good news: With the move to Front Row Agile, all streaming licenses are being moved from six-month licenses to permanent licenses. That’s right—you’ll be able to watch these videos long after Dr. Who goes off the air.

And to celebrate, I’ve cut the price of Agile Estimating and Planning licenses in half. It used to be $200 for a six-month streaming license. Now it’s $100 for a permanent streaming license. The Scrum Repair Guide is available at the same price. Each of these courses offers well over 3 hours of video you can watch over and over.

If you want to watch without an Internet connection, download licenses are still available for each course. Quantity discounts are available and we have an innovative approach to company (site) licenses—email us at info@frontfrowagile and we’ll tell you more.

FrontRowAgile.com is committed to becoming the leading provider of video-based training on agile and Scrum. Sample videos from each course are available on the site.

Press Inquiries:

If you are interested in publishing a review of FrontRowAgile.com or of either course, please email us for one of a limited number of promotional licenses we are making available. Let us know which course you’re interested in reviewing and a link to where you would publish the review.

Software Development Mantra

From the Editor of Methods & Tools - Mon, 04/07/2014 - 14:51
We believe developers should have a particular attitude when writing code. There are actually several we’ve come up with over time – all being somewhat consistent with each other but saying things a different way. The following are the ones we’ve held to date:Avoid over- and under-design. Minimize complexity and rework. Never make your code worse (the Hippocratic Oath of Coding). Only degrade your code intentionally. Keep your code easy to change, robust, and safe to change.Source: “Essential Skills for the Agile Developer – A Guide to Better Programming and Design”, Alan Shalloway, Scott ...

SPaMCAST 284 – Evan Leybourn, Directing The Agile Organization

www.spamcast.net

http://www.spamcast.net

Listen to the Software Process and Measurement Cast 284. SPaMCAST 284 features our interview with Evan Leybourn, author of Directing the Agile Organization. We had a wide-ranging discussion on Agile business management. Agile is not just for IT anymore!

Evan’s Bio

Evan is an experienced leader, coach and published author in the developing field of Agile Business Management; applying the successful concepts and practices from the Lean and Agile movements to corporate management. Evan has a passion for building effective and productive organizations, filled with actively engaged and committed staff while ensuring high-levels of customer satisfaction. Evan’s experiences when holding executive and board positions in both private industry and government has driven his passion for lean business management.

His background in Agile Project Management and Business Intelligence informed his understanding of the need for evidence-based decision making and quantitative analysis, to measure corporate success. As well as writing “Directing the Agile Organization“, Evan currently consults to organizations around Australia and SE Asia on Agile management and governance.

All of Evan’s contact information and blog can be accessed on his website

Buy the book Paper Kindle

Get in touch with us anytime or leave a comment here on the blog. Help support the SPaMCAST by reviewing and rating it on iTunes. It helps people find the cast. Like us on Facebook while you’re at it.

Next week the essay will be a collection of questions you have asked on the blog, on the phone or in person. They are great questions when we discussed them one on one, it is time to share the answers with a broader audience.

Upcoming Events

QAIQuest 2014

I will be facilitating a Âœ Day tutorial titled Make Integration and Acceptance Testing Truly Agile. The tutorial will wrestle with the flow of testing in Agile projects and will include lots of practical advice and exercises. Remember that Agile testing is not waterfall done quickly. I will also be around for the conference and look forward to meeting and talking with SPaMCAST readers and listeners.  More confernce information   ALSO I HAVE A DISCOUNT CODE
. Email me at spamcastinfo@gmail.com or call 440.668.5717 for the code.

StarEast

I will be speaking at the StarEast Conference May 4th – 9th in Orlando, Florida.  I will be presenting a talk titled, The Impact of Cognitive Biases on Test and Project Teams. Follow the link for more information on StarEast. ALSO I HAVE A DISCOUNT CODE
. Email me at spamcastinfo@gmail.com or call 440.668.5717 for the code.

I look forward to seeing all SPaMCAST readers and listeners at all of these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

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

Available in English and Chinese.

 

 


Categories: Process Management

SPaMCAST 284 – Evan Leybourn, Directing The Agile Organization

Software Process and Measurement Cast - Sun, 04/06/2014 - 22:00

Listen to the Software Process and Measurement Cast 284. SPaMCAST 284 features our interview with Evan Leybourn, author of Directing the Agile Organization. We had a wide-ranging discussion on Agile business management. Agile is not just for IT anymore!

Evan’s Bio

Evan is an experienced leader, coach and published author in the developing field of Agile Business Management; applying the successful concepts and practices from the Lean and Agile movements to corporate management. Evan has a passion for building effective and productive organizations, filled with actively engaged and committed staff while ensuring high-levels of customer satisfaction. Evan's experiences when holding executive and board positions in both private industry and government has driven his passion for lean business management.

His background in Agile Project Management and Business Intelligence informed his understanding of the need for evidence-based decision making and quantitative analysis, to measure corporate success. As well as writing "Directing the Agile Organization", Evan currently consults to organizations around Australia and SE Asia on Agile management and governance.

All of Evan’s contact information and blog can be accessed on his website

Buy the book Paper Kindle

Get in touch with us anytime or leave a comment here on the blog. Help support the SPaMCAST by reviewing and rating it on iTunes. It helps people find the cast. Like us on Facebook while you’re at it.

Next week the essay will be a collection of questions you have asked on the blog, on the phone or in person. They are great questions when we discussed them one on one, it is time to share the answers with a broader audience.

Upcoming Events

QAIQuest 2014

I will be facilitating a ½ Day tutorial titled Make Integration and Acceptance Testing Truly Agile. The tutorial will wrestle with the flow of testing in Agile projects and will include lots of practical advice and exercises. Remember that Agile testing is not waterfall done quickly. I will also be around for the conference and look forward to meeting and talking with SPaMCAST readers and listeners.  More confernce information   ALSO I HAVE A DISCOUNT CODE…. Email me at spamcastinfo@gmail.com or call 440.668.5717 for the code.

StarEast

I will be speaking at the StarEast Conference May 4th – 9th in Orlando, Florida.  I will be presenting a talk titled, The Impact of Cognitive Biases on Test and Project Teams. Follow the link for more information on StarEast. ALSO I HAVE A DISCOUNT CODE…. Email me at spamcastinfo@gmail.com or call 440.668.5717 for the code.

I look forward to seeing all SPaMCAST readers and listeners at all of these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI's mission is to pull together the expertise and educational efforts of the world's leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

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

Available in English and Chinese.

 

 

Categories: Process Management

Swarming

Team members should swarm to a problem like tourists to a photo opp

Team members should swarm to a problem like tourists to a photo opp

Swarming is common behavior in an Agile team. Swarming occurs when a group of team members work together on a single story or impediment to break a log jam. It helps to overcome problems and bottlenecks so the team can deliver functionality quickly and often. Swarming provides a team with a mechanism focus on impediments and remove them immediately. Studies support that the act of swarming, as an act of kindness, generates further acts of kindness (within limits).

In an article titled The Science of ‘Paying It Forward’ in the New York Times on Sunday, March 16, 2014, Melena Tsvetkova and Michael Macy describe an article they published in the journal PLoS One.  Their research found that receiving and observing generosity can increase the likelihood of being generous, however in some cases, if the level generosity is too high it can shift have the opposite effect. When the level of observed generosity is perceived to be too high the observer is less likely to pay it forward and be comes a bystander rather than helping some someone else. The findings suggest that the act of helping a fellow team member out makes it more likely that the recipient of the behavior will also help his/her fellow team members out when they have a problem.

The findings carry a cautionary note for teams, Scrum Masters and coaches. If one person always is there to save the day it is possible to turn others in the team into bystanders. Also it is possible for the other team members to expect help before they exhausted all options.  The ability to ask for help and expect the team to swarm to the problem too easily is a form of moral hazard that can cause other team members to feel that they are being taken advantage.  If this perception takes root, it  will reduce the possibility that the team will swarm to problems.

Scrum Masters or coaches need to be aware that swarming, like any act of kindness, is apt to ripple thought the team. Team members helping each other out in order to overcome impediments is an important activity in effective Agile teams. Coaches need to ensure that swarming is not limited to an individual (or small group), but is balanced across the team to reduce the risk that team members won’t respond when all hands are needed on deck.


Categories: Process Management

Testing First Really Is Different Than Testing Last

There really is a difference  . . .

There really is a difference . . .

Classic software development techniques follow a pattern of analysis, design, coding and testing. Regardless of whether the process is driven by a big upfront design or incremental design decisions, code is written and then tests are executed for the first time. Test plans, scenarios and cases may well be developed in parallel with code (generally only with a minimum of interaction), however execution only occurs as code is completed. In test-last models, the roles of developer and tester are typically filled by professionals with very different types of training and many times from separate management structures. The differences in training and management structure create structural communication problems. At best the developers and testers are viewed as separate but equal, although rarely do you see testers and developers sharing tables at lunch.

Testing last supports a sort of two tiered development environment apartheid in which testers and developers are kept apart. I have heard it argued that anyone that learned to write code in school has been taught how to test the work they have create, at least in a rudimentary manner, therefore they should be able to write the test cases needed to implement test-driven development (TDD). When the code is thrown over the wall to the testers, the test cases may or may not be reused to build regression suites. Testers have to interpret both the requirements and implementation approaches based on point in time reviews and documentation.

Test-first development techniques take a different approach, and therefore require a different culture. The common follow of a test first process is:

  • The developer accepts a unit of work and immediately writes a set of tests that will prove that the unit of work actually functions correctly.
  • Run the tests.  The tests should fail.
  • Write the code need to solve the problem.  Write just enough code to really solve the problem.
  • Run the test suite again.  The test should pass.

Most adherents of Agile development methods have heard of TDD which is the most common instantiation of the broader school of test-first development (TFD).  TDD extends TFD by adding a final refactoring step to the flow in which developers write the tests cases needed to prove that unit of work solves the business problem and is technically correct. Other variants, such as behavior-driven and acceptance test-driven development, are common.  In all cases the process follows the same cycle of writing tests, running the tests, writing the code, re-running the tests and then  refactoring the only difference being the focus tests.

TFD techniques intermingle coding and testing disciplines, creating a codependent chimera in which neither technique can exist without the other. For TFD to work most effectively coders and testers must understand each other and be able to work together. Pairing testers and developers together to write the test case either for component/unit testing (TDD), behavior-driven tests (BDD) or acceptance testing (ATDD) creates an environment of collaboration and communication.  Walls between the two groups will be weak, and over time, torn down.

Test-first development and test-last development techniques are different both in terms of the how work is performed and how teams are organized. TFD takes a collaborative approach to delivering value, while test-last approaches are far more adversarial in nature.


Categories: Process Management

Doing The Right Thing Right

2377653578_ae3ac7e860_b

Being on time is one aspect of ethical behavior

Ethics are the moral principles that govern behavior.  The principles that underlie ethics help us judge what is right or wrong. Team members on a project team are presented with a nearly continuous stream of choices to test their principles. Over the years I have seen choices that were clearly unethical, some that might be in a gray area and the majority have been ethical or at least neutral. An example of a clearly unethical decision was when a project showed a project as having a green status when it was clear that it was in deep trouble. I was recently asked why not unit testing code when the organizations standard process called for it to be unit tested was an ethical issue rather than just a failure to follow best practices. Unit testing is an expected behavior for most coders. There are at least two reasons this behavior is an ethical issue. The first is when a developer does not unit test the code they have written they are making someone else responsible for finding their mistakes. The second reason is because unit testing is the expected behavior in their methodology (and 99.9% of the coding methods I am aware of).

Here are four general attributes of ethical behavior:

  1. Reliability: A person’s actions should match the behavior they have committed to follow. Many organizations spend substantial time and effort defining techniques and methods with policies to ensure they are followed.  Deciding not to follow the standard process is generally not ethical behavior. In our unit testing example, most methodologies specifically call for developers to unit test their code. When a coder doesn’t unit test they are damaging their reliability. They can no longer be trusted to behave as expected by others following the process.
  2. Responsibility:  Responsibility is about the duty to deal with your actions. In our unit testing example, not unit testing makes someone else responsible for finding and removing your mistakes.
  3. Respectfulness:  Team members must be aware and have regard for the feelings of those around them. Respectful does not mean avoiding tough decisions or conversations, but rather being aware of how deeds, actions and words affect those you and doing your best to help deal with those effects. Making someone else clean up your code is not respectful to the next developer or tester.
  4. Fairness: Actions and decisions need to be objective, evenhanded and consistent. Not following a mandated or agreed upon process does not represent  consistent  behavior.

Why do these four attributes matter when discussing ethics of project team members? It can be boiled down to reputation. In most Agile teams, being able to be counted on to do the right thing is essential for long-run influence.  Self-organizing and self-managing teams which are core feature of Agile need team members to perform within ethical boundaries and to be able to influence each other to do the right thing and to do the right thing right.


Categories: Process Management

Another Learning Style Model

 

Every team member has a different learning style that has to be synced.

Every team member has a different learning style that has to be synced.

Another learning style model is built on four dimensions of learning styles. The dimensions of the Index of Learning Styles developed by Dr Richard Felder and Barbara Soloman are each described as a continuum.  Each continuum is bounded by opposite attributes of a learning style. An individual could map him or herself on each of the continuum to generate rich understand of their learning style. They are summarized below:

Untitled2

Mature teams generally are comprised of mix of learning styles. A mixture of styles can be complementary. For example, many IT groups I have worked with have at least one big picture person and several more linear learners.  What I generally do not see are individuals that sit at the extremes of any of the dichotomies. Individuals that sit at an extreme tend to be more difficult to draw into the group which impacts the ability to communicate and the ability of team members to trust each other.

One use of this type of model is to map teams.  For example, if we use the example used in Learning Styles and Communication Problems in a mapping exercise, I would judge the three personalities Lawyer (L), Talker (T) and Diagrammer (D) to fall as below:

Untitled1

The mapping exercise can be used to flag extremes that might cause trouble for the team. As noted in the example, the overall team was having issues staying focused when the Lawyer was presenting due to the sequential style being used. Using a mapping approach early in formation of the team can provide the coach with the impetuous for training exercises to sensitize the team to the disparate learning styles.

I suggest doing this exercise as a team when generating the team charter. The process I follow is:

  1. Place each of the descriptors on separate sticky notes and then place them on the wall so that all four continuums are visible.
  2. Review and discuss the meaning of each attribute.
  3. Have each team member mark where they believe they fall on each of the attribute continuums
  4. Discuss how the team can use the information to more effectively communicate.

Opposites might attract in poetry and sitcoms, however rarely do opposite learning styles work together well in teams without empathy and a dash of coaching. Therefore coach and teams need to have an inventory of learning styles on the team. Models and active evaluation against a model are tools to generate knowledge about teams so they can tune how they work to maximize effectiveness.


Categories: Process Management

Learning Styles and Communication Problems

Include differences (learning styles, that is)

Include differences (learning styles, that is)

The team that completes a project will be different from the one that began the project. Each person on the team will have a range of individual experiences, and presumably, they will learn from these experiences. A mismatch of learning styles can result in communication problems. Communication problems act as a filter on what each individual learns by blocking or altering what the learner perceives.

Learning styles reflect an individual’s preference for how they will learn. In many cases individuals mirror their own learning style when share with others. Most, if not all, teams I have been associated with over my career have been comprised of individuals with different learning styles. This means that to effectively communicate and transmit knowledge, each team member must understand the learning styles of their team members (this is another reason why stable teams generally have higher levels of performance).

An example of the impact when team members do not understand each other’s learning style can be seen in a team I recently observed.  The team is a relatively new team and is distributed, with most interactions occurring via teleconference, which complicates bonding. Most team members have not had time to adjust to each other’s learning style; therefore members use their own learning patterns as a default when interacting. For example, one team member follows the logical/Lawyer learning style. When presenting information they build a case – fact by fact – in great detail. No one else on the team leverages this as their primary learning style. The great level of detail and the slow (but relentless) build to the conclusion leads to frustration and disengagement. On the same team, another member is verbal learner/Talker.  This person needs learns by hearing, and in many cases, by vocalizing each point.  This person presents information in the same manner as they learn, talking it through (with lots of Keynote slides … with no pictures). In both cases because the members are not aware of the learning styles of other team members communication is inefficient (and my observation is that it can be ineffective).

Teams that are centrally located generally recognize learning style mismatches based on visual and empathetic feedback and can self-correct (assuming that team members actually pay attention when they get together). Distributed teams generally need to take a more active approach to learning each other’s preferences. I recommend the following approach which can be used as a team building exercise or as a retrospective exercise:

  1. Before the exercise, create a couple of canned scenarios.  For example:
    1. Scenario One:  Pass status information about a trouble task, including a plea for help.
    2. Scenario Two:  Build consensus for a design decision.
  2. Have each team member identify their primary and secondary learning style.
  3. Share these styles with the team.
  4. Once all team members have shared their style, have each team member select a method that is not their primary or secondary style and have them convey the information needed in complete each scenario. (Allow 5 minutes for preparation).

The goal of exposing the team to other types of learning styles is to push each person outside their comfort zone.  This serves multiple purposes. First, the process helps to build empathy. The process also reinforces the awareness that, on a diverse team, all messages need to be shared in a variety of ways so that multiple learning styles can easily absorb the information.  Finally, by learning and becoming sensitive to other learning styles, individual team members will expand their ability to recognize nuances in communications that lay outside their normal learning style. This will ultimately increase the effectiveness and efficiency of the team.


Categories: Process Management