Tag Archives: agile

Extremely Short Iterations – Agile 2008 Experience Report

Infoq published the video recording of my talk at Agile 2008 titled “Extremely Short Iterations as a Catalyst for Effective Prioritization of Work“.


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Book Commentary

AGILE Project Management with Scrum -A book by Ken Schwaber

Prior to the Certified ScrumMaster seminar I attended in August 2008, I read the book by Ken Schwaber called Agile Project Management with Scrum based on a recommendation from Mishkin Berteig.    After attending the seminar and becoming certified as a ScrumMaster I re-read the book.   The second reading was much more valuable than the first for I had a much better understanding of Scrum.   Here are my comments on this book.

What have I learned?

1.    The adoption of Scrum methodology is more about changing roles and behaviours than it is about embracing a new process.

It was obvious to me and to Ken that one of the greatest challenges facing those individuals when moving from a their current environment to a scrum environment was that they would need to change their behaviours.    In the former environment the team member would be directed and inspected based on what their project manager told them to do.  The PM is the boss and the team members are somewhat powerless.  In Scrum the team members take responsibility for their commitments and communicate their accomplishments on a daily basis.  The hardest change occurs when the project manager is asked to become a ScrumMaster.  The project Manager is familiar with assigning tasks and personally inspecting results. In the scrum environment they are the servants of the team, removing obstacles and facilitating the process.   As Ken states in this book some project managers have great difficulty transitioning into the ScrumMaster role.  They are unwilling to give up the power and position as a project master.   It is hard to move from the leader of the pack to become the sheep dog herding the sheep!

2.    Scrum is unforgiving for if you do not apply the fundamental principles it is likely your efforts to adopt Scrum will fail.

As I reviewed the numerous case studies Ken chronicled is was apparent that when organizations, Team members, Product Owners and ScrumMasters followed the terms, conditions and guidelines of the Scrum methodology, they tended to deliver on their commitments.   When they misunderstood, misused or deleted some portion of the methodology they tended not to accomplish their objectives.   The methodology is well thought out and works in many situations when used appropriately.

3.    Scrum enhances individual and team expertise.

I agree and totally support Ken’s opinion about the value of Scrum.   I have no doubt the individual team member is empowered and has a greater sense of achievement.    Obviously based on his case studies, Ken builds a strong case that Scrum allows the team to deliver quicker.  The process is more change adaptive, responsive to customer needs, timely and economical than traditional methods.   Greater energy and capacity is released in the team and individual team members.


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

3-Day Certified ScrumMaster Training – Toronto

Agile Project Management – Certified ScrumMaster Training
Offered by Berteig Consulting Inc. www.berteigconsulting.com

Agile methods promise early, continuous and accelerating return on investment for stakeholders and a high level of job satisfaction for teams. Agile methods are appropriate for a variety of projects including program development, materials development, new product development, IT projects and software development outsourcing. In this three-day course, you will learn the foundational skills of agile process facilitation and project management, focused on the role of the ScrumMaster (also known as: Agile Project Manager, Process Facilitator, Team Coach).
What You Will Learn:

In this 3-Day course participants learn how to guide a team, a project, or an organization into a process of rapid delivery of valuable results. Exercises, case studies, and examples are used to assist participants to develop the knowledge, skills, capabilities and insights needed to make the shift from traditional management practices to Agile practices.

In this workshop you will learn:
• agile project management practices that enable hyper-productive projects;
• agile processes and facilitation tools that improve the productivity of the team;
• agile collaboration methods to remove the barriers between the team and the customer; and,
• to improve the lives of the team members by facilitating creativity and empowerment.
Why is this ScrumMaster course better than others out there?

Our Agile Project Management / ScrumMaster course is unique in many ways. Here is what you get when you attend our course:
• Three intensive days of training with exercises, simulations, discussion and lecture
• Classroom management using agile methods so that you can learn by example
• Course material designed for the ScrumMaster/Project Manager role not diluted to accommodate other roles
• Taught by one of the most experienced Certified Scrum Trainers in the world
• Low class size with a maximum of 15 students compared to some trainers with 20, 30 or even 50 students!
• Electronic copies of all course materials including free updates forever
• 24 PDUs if you are a member of the Project Management Institute
• Certification as a ScrumMaster at the ScrumAlliance that never expires
• One year paid membership in the ScrumAlliance

• Light breakfast and lunch all three days

Note: To learn more about this course and to register, please visit our website:

http://www.berteigconsulting.com/AgileScrumCertificationCSMTrainingOctober2008TorontoOntarioCanada


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Finally – a solid metric for code quality.

Bob C. Martin (Uncle Bob to you and me) suggested, in his “quintessence” keynote at the Agile2008 conference that he had the perfect metric for code quality. Cyclomatic complexity and others were interesting mostly to those who invented them, etc. His answer was brilliant, and was easily measured during code reviews:

WTFs per minute

I love it. All you need is a counter and a stop-watch. Start code-review and start watch and start clicking anytime you see code that makes you say or think “What the F???”. This dovetails nicely with his original recommendation for a new statement in the agile manifesto: “Craftsmanship over Crap”.


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

First Day of Agile 2008 Conference

The first day of the Agile 2008 Conference was fabulous!  I’m working with five other great people including my wife, Melanie, my father, Garry, and three good friends: Paul, Travis and Laila.  We have set up a beautiful booth designed by my brother, Alexei Berteig.  Working at the booth has been a tiring yet exhilarating experience.  Before the conference we received Boothmanship Training from The Portables.  The people at The Portables have been excellent and I highly recommend them to anyone embarking on a booth display at a conference.

Today I delivered the first of my two presentations at the conference.  The thirty minute experience report: “Extremely Short Iterations as a Catalyst for Effective Prioritization of Work” was well received.  There were about 25 people in attendance and despite the short time for questions, there were some good ones.  I enjoyed delivering the presentation and it was filmed for later publication on InfoQ.  I also received highly positive feedback after the talk.  On Thursday, I am giving a much more substantial presentation titled “Meta-Agile: Using Agile Methods to Deliver Agile Training“.  This will be a three hour workshop in two parts: a 90 minute presentation, and then a 90 minute participatory patterns workshop.  If you are a trainer or coach, I highly recommend attending this one!

I also ran into many friends… too many to list, in fact.  It is surprising to me to see how many people I know in this community.  There are over 1500 people at this agile conference, and I can’t walk more than 20 steps without running into someone I know.  One other really cool thing is that everyone is commenting on how much they like the notebooks that were included in the conference bag – highly popular.  In fact, three people have commented that it was the only useful thing in the bag… which is actually a bit of an exaggeration since the conference program was also in the bag and I suspect that it might be just a wee bit more useful 🙂  Nevertheless, the feedback has been great.

Come check us out at our booth if you are at the conference – it’s unmistakable – strong red backdrop with the Berteig Consulting logo across the top.  We also have a great raffle so be sure to drop off your raffle entry which is found in your notebook pocket.


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Dependecy Injection on J2ME/CLDC devices.

This post is a little geeky and technical and product-related for AgileAdvice, and is a shameless self-promotion. Nevertheless, since testability, test-driven-development, and incremental design are non-exclusive sub-topics of Agile, I though I’d report this here anyway.

Many developers use the Dependency Injection and Inversion of Control (IoC) patterns through such IoC containers as Spring, Hivemind, Picocontainer, and others. They have all sorts of benefits to testability, flexibility, etc. that I won’t repeat here, but can be read about here, here, and here. A great summary of the history of “IoC” can be found here. J2ME developers, however, especially those on limited devices that use the CLDC configuration of J2ME, cannot use the substantial number of IoC/DI containers out there, because they nearly all rely on reflection. These also often make use of APIs not present in the CLDC – APIs which could not easily be added. Lastly there’s a tendency among developers of “embedded software” to be very suspicious of complexity.

In working out some examples of DI as part of a testability workshop at one of my clients, I whipped up a quick DI container, and being the freak that I am, hardened it until it was suitable for production, because I hate half-finished products. So allow me to introduce the Israfil Micro Container. (That is, the Container from the Israfil Micro project). As I mention in the docs, “FemtoContainer” just was too ridiculous, and this container is smaller than pico-container. The project is BSD licensed, and hosted on googlecode, so source is freely available and there’s an issue/feature tracker, yadda yadda.

Essentially I believe that people working on cellphones and set-top boxes shouldn’t be constrained out of some basic software design approaches – you just have to bend the design approach to fit the environment. So hopefully this is of use to more than one of my clients. It currently supports an auto-wiring registration, delayed object creation (until first need), and forthcoming are some basic lifecycle support, and a few other nicities. It does not use reflection (you use a little adapter for object creation instead), and performs quicker than pico-container. Low, low overhead. It’s also less than 10 classes and interfaces (including the two classes in the util project). It’s built with Maven2, so you can use it in any Maven2-built project with ease, but of course you can always also just download the jar (and the required util jar too). Enjoy…

P.S. There are a few other bits on googlecode that I’m working on in the micro-zone. Some minimalist backports of some of java.lang.concurrency (just the locks), as well as some of the java.util.Collections stuff. Not finished, but also part of the googlecode project.


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Cool New Tool – WhiteBoardWiki

Check it out: whiteboardwiki.org.  Looks like it’s very flexible.  Has some bugs and lots of basic features yet to be added, but since its open source, we can all contribute!!!  Development is being organized in an agile fashion using a product backlog.  Fun.


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile Announcements

It seems that Berteig Consulting is blocked from China, so I’ve made a new site called Scrum Beijing to promote the ScrumMaster training I do there.

Also, the price has been reduced on the Scrum Study Guide and the web site now includes screen shots and a bit more useful information.

Berteig Consulting is starting to formally market OpenAgile as a method for helping small businesses manage their work (in any industry).  Heck, we’re using it ourselves.

And of course, a reminder about the Agile 2008 conference happening in Toronto in August – don’t miss it, it’s going to be fantastic!


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Scrum Smells Catalog

Mark Levison has written up a great list of Scrum Smells on his blog Notes from a Tool User.  Check them out!  There is a lot of great information there.  He also asks your help: if you know of common problems with Scrum, see if you can add them to the list!


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Measuring Process Improvements – Cycle Time?

One of the challenges with agile methods is to get a clear perspective on how to measure process improvements. I recently had a brief discussion with a C-level executive at a small organization about this. His concern was that cycle time was meaningless because it depended so much upon the size of the work package. So how do we use cycle time as a meaningful measurement? What else can we use to measure process improvement?

Let’s look at the difference in measuring cycle time in an agile vs. non-agile environment. Then we’ll get to other measurements.

Cycle Time , Waterfall and Agile

First, let’s define cycle time. From iSixSigma we have:

Cycle time is the total time from the beginning to the end of your process, as defined by you and your customer. Cycle time includes process time, during which a unit is acted upon to bring it closer to an output, and delay time, during which a unit of work is spent waiting to take the next action.

This definition is important because it gives us a clue about the potential difference between a waterfall vs. agile method of delivering value. Let’s imagine the typical process used in a waterfall environment. The following are the high-level steps:

  1. Customer / User / Stakeholder sees a need, validates it and submits a request to have that need fulfilled. This is when we start the clock on cycle time.
  2. The fulfillment organization (IT, Product Development, R&D) puts the request in a queue, backlog or requirements management system.
  3. Along with other requests, the fulfillment organization schedules the work on the request, usually by creating a project to fulfill it and other related requests. The project is estimated at a high level, the current status of in-flight projects is noted, and the new project is prioritized relative to other projects.
  4. At some point, based on the schedule and the reality of the work on other projects, the project containing our customer’s request is started. Here, “started” means that detailed requirements are gathered.
  5. After sufficient requirements are gathered, a detailed technical analysis is done including architecture, high-level design, risk analysis, etc.
  6. Development begins. (Note: many people mistakenly start measuring cycle time here.)
  7. Developers and testers work to validate the results of development and fix any problems discovered.
  8. Final acceptance testing is done.
  9. The results of the project are deployed to users, sold to the client, or in some other way passed back to the original requestor. This is when we stop the clock on cycle time.

So from the start of the customer request formally submitted to the time that the fulfillment of that request is made is our true cycle time. There are a few important things to note here. First, there is a queue of work based on requests made but not yet scheduled. There is another queue for work scheduled but not yet started. We know that if we can reduce the size of these queues, we can improve cycle time in a general sense. Second, we know that most organizations of any significant size will have different queues based on the urgency of the request. For example, a high severity bug discovered in the production system of a company’s largest client will be treated differently than a wish list item for a small not-yet-client. These two requests won’t even go in the same queue: the high priority problem will be quickly escalated to a support or development team that can work on it immediately. Third, it is tempting for the development group to measure their local cycle time. This is a Really Bad Idea since it leads to sub-optimizing behaviors. For example, it is easy for the development team to improve their cycle time by sacrificing quality… but this just causes the QA cycle time to increase, and probably the overall cycle time (true cycle time) is affected more than the local improvement in the development group’s cycle time.

Now let’s look at the steps that occur in an ideal agile environment:

  1. As before, the Customer / User / Stakeholder sees a need, validates it and submits a request to have that need fulfilled.
  2. That request is immediately placed in a ready state for the next iteration (cycle, sprint) of a delivery team. Elapsed time: maximum one month.
  3. Team completes the request including all work to actually deliver/deploy and work is delivered to the stakeholder at the end of the iteration. Elapsed time: maximum two months.

So the ideal method of doing agile has a maximum cycle time of two months to deliver from the time a request is made… how many teams are doing this? Not many.

The ideal is extremely difficult to accomplish. Getting to that state requires that the development organization catches up to the business side so that there are zero pending requests at the start of each iteration. It also requires that the business side users and stakeholders are able to articulate their requests so that they are small, and appropriately detailed for the team doing the work.

A realistic agile implementation actually is a lot more messy. Depending on the type of request, the cycle time for a piece of work can vary widely. Some low priority items may take years even in an agile environment. A low priority request is made and approved but then never quite makes it into a project… and then once in a project never quite makes it to the top of the team’s product backlog. This is interesting to look at sometimes, but it points out another important aspect of measuring cycle time: mostly we care about average cycle time (or some other statistically interesting aggregate measure).

The predominant factor in most organizations’ cycle time is the number and size of the queues they use as work is processed. In most organizations there are several queues and most of them contain large numbers of requests or bits of work in process. Queues represent huge amounts of waste. It is easy to see that queue size and cycle time are closely related: the more items in a queue, the longer the cycle time.

This leads to a simple conclusion: regardless of lifecycle approach, reducing the size of an organization’s queues is one of the easiest ways to reduce cycle time. What are some common queues? There are often queues of projects, queues of enhancement requests, queues of defects to be fixed, queues of features, queues of tasks, queues of email (large inboxes), queues of approval requests, queues of production database changes. The number of queues increases the more an organization is oriented around functional groups, and the number of queues decreases the more an organization arranges work to be handled by cross-functional teams.

Cycle Time and Work Package Size

This is where queueing theory and agile methods intersect really well. Cycle time is related to the load on your system, in particular your units of work processing. In most organizations, teams are created to handle work. The more work given to a team simultaneously, the higher their utilization level. Many organizations like high utilization levels because it gives them a guarantee that people are doing valuable work all the time that they are paid to work. This is a completely false benefit and in fact is extremely destructive to overall productivity. From queueing theory we know that the cycle time for a piece of work increases exponentially to the utilization level. We see this whenever we over-load a server… but for some reason we fail to see this when we overload a person or a team or an organization even though it still happens.

Cycle time is also related to the variability in the size of the work packages. Low variability means that the exponential factor related to load is low, and high variability means that the exponential factor is high. In other words, if you have a highway that only allows motorbikes, you can have a very high load without getting bad traffic jams. On the other hand, if you have a highway that allows anything on it, you get traffic jams even with low levels of load. This is why HOV or commuter lanes and the left lane in multi-lane highways don’t typically allow transport trucks and buses. This result from queueing theory is not intuitively obvious so it is even harder for us to apply to software development.

But apply these two ideas, load and work size variability, we must if we wish to create a high performance development organization. The simplest way to do this is to have a single team work on a single project at a time and use iterations to ensure that the work being done is always exactly the same size – the size of the iteration.

Improving Cycle Time

It is possible to have very short iterations and still have a long cycle time. Many organizations make a few common mistakes with agile that cause this. If the work done inside each iteration is restricted to pure development work and everything else is done outside the iterations, then cycle time likely stays long. A common example of this is having the QA folks remain separate from the development team and do their work after a development team releases their work.

There is really only one way to avoid this: have a comprehensive definition of “done” that is met by the team every single iteration. This ensures that all work from idea to release for a given customer request is done inside a single iteration. A side effect of this is that all the pieces of work need to be small. It also gets rid of all the queues except one: the queue of ideas approved for delivery. With a single queue to manage, it becomes easy to measure cycle time, and therefore easy to improve it.

Improving cycle time can now be done in a few ways:

  1. Put a cap on the number of items in the work queue. Since cycle time is directly related to the size of the queues in a system, this is a sure way of putting a maximum on cycle time.
  2. Go through all existing requests and throw as many away as possible. This can be tough to do, but if you are able to do a cost benefit analysis, you will typically find that older items in the queue are no longer worth while.
  3. Provide more stringent gating functions for allowing requests onto the queue. The few items added, the faster the size of the queue is reduced.
  4. And of course, increase the performance of your team(s) so that they go through items on the queue more quickly.

Productivity and Cycle Time

Once you have control of cycle time, it is possible to make reasonable measurements of productivity and two more metrics become extremely important (not that they weren’t important before, but they are easier to work with now). The first is Return on Investment (ROI) and the second is customer satisfaction.

ROI is in its simplest form a measure of how much benefit there is to doing something as compared to the cost of doing it. It takes into account the importance of time and timing, the importance of other options you may have, and of course, hopefully takes into account the business reality of your work. It also takes into account costs.

In software development, the primary cost is the cost of the staff doing the work, and the time factor is your cycle time (Ah! that’s where we use it). If you have a consistent team working on iterations that are always the same size and if you have little or no work being done outside of the iterations, it is very easy to calculate ROI in a useful way. Simply measure how much value a given iteration worth of work will generate and divide by the cost of the team for an iterations (and if the team is not yet doing work as it comes in, take into account the time value of money since the work might not be done for several iterations). Now, productivity is simply a measure of the Return for each Team-Iteration. Dollars/iteration. Simple. If the team’s productivity goes down, you can ask some really simple questions:

  • Did the expected return of the work go down? If so, is there more valuable work the team should be doing? This becomes an opportunity for product improvement.
  • If not, what caused the team to get less done? Was the work harder than expected? Was there a skill gap? Was there an organizational obstacle that was revealed? Was someone sick? This becomes an opportunity for process and team improvement.

Customer satisfaction can be measured in many ways. If you have already started using agile practices, there is a good chance that your customers will already be more satisfied than they were before. This will show up informally through word-of-mouth. However, it is good to have a more systematic way of measuring customer satisfaction. One of the simplest and most commonly used methods of measuring customer satisfaction is the Net Promoter Score. From WikiPedia:

Companies obtain their Net Promoter Score by asking customers a single question (usually, “How likely is it that you would recommend us to a friend or colleague?”). Based on their responses, customers can be categorized into one of three groups: Promoters, Passives, and Detractors. In the net promoter framework, Promoters are viewed as valuable assets that drive profitable growth because of their repeat/increased purchases, longevity and referrals, while Detractors are seen as liabilities that destroy profitable growth because of their complaints, reduced purchases/defection and negative word-of-mouth. Companies calculate their Net Promoter Score by subtracting their % Detractors from their % Promoters.

The Net Promoter Score is closely linked to quality including the hard-to-measure parts of quality like responsiveness, ease of use, and fitness for purpose.

Cycle time also affects customer satisfaction. The faster you can respond to requests by customer, users or other stakeholders, the more likely they are to be satisfied. This happens for two reasons: fast response time means that solutions are more likely to still be useful and correct when actually delivered, and it also gives more opportunities for feedback.

In fact, if we look at these three measures, cycle time, ROI and customer satisfaction, we see that they form a mutually supporting and cross-checking system of ensuring productivity and effectiveness. Measuring anything else muddies the waters and can cause sub-optimal behaviors. The real challenge for most teams is realizing that all their local measures of performance and effectiveness may actually be causing harm (unintentionally) because they draw the team’s attention away from the three organizationally important measures.

Cycle time is the measure that is most closely related to process improvements, but ROI and customer satisfaction should also be used to ensure that process improvements don’t accidentally harm the organization.


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcing: Talks at Agile 2008

After a rigorous submission process, a total of five presentations by Berteig Consulting staff and affiliates are accepted into the program for the Agile 2008 conference in Toronto. The five presentations are:

Meta-Agile: Using Agile Methods to Deliver Agile Training (3 hours, workshop format) – Mishkin Berteig

Extremely Short Iterations as a Catalyst for Effective Prioritization of Work (30 minutes, experience report) – Mishkin Berteig

The Learning Circle: An Evolution of Agile for Learning Environments (30 minutes, experience report) – Garry Berteig

Using Agile Engineering Tools and Practices to Achieve Organizational Change (90 minutes, talk) – Christian Gruber

Maven and Continuum – Building an Ecosystem for Agile Builds and Testing (3 hours, workshop) – Christian Gruber

Berteig Consulting is also using the vendor talk slot to provide additional value to conference goers with an introduction to using OpenAgile to run a small business.

OpenAgile: A Method for Business Development (30 minutes, vendor talk) – Paul Heidema and Mishkin Berteig


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Delivering Successful Agile Projects – A Team Approach

Last week I gave a talk in Waterloo, Ontario on the topic of Delivering Successful Agile Projects – A Team Approach
.  The slides and a bit more info can be found on the Berteig Consulting site.  There was a great deal of interest so I have also scheduled a public agile project management / certified ScrumMaster course in Waterloo.


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Quality is not an attribute, it’s a mindset

This was actually cribbed from a Bruce Schneier blog post about security…

Security engineers see the world differently than other engineers. Instead of focusing on how systems work, they focus on how systems fail, how they can be made to fail, and how to prevent–or protect against–those failures. Most software vulnerabilities don’t ever appear in normal operations, only when an attacker deliberately exploits them. So security engineers need to think like attackers.People without the mindset sometimes think they can design security products, but they can’t. And you see the results all over society–in snake-oil cryptography, software, Internet protocols, voting machines, and fare card and other payment systems. Many of these systems had someone in charge of “security” on their teams, but it wasn’t someone who thought like an attacker.  

There’s an interesting parallel between this statement and how most software quality is handled. Quality and Security are similar. In fact, I see security as a very specific subset of quality-mindedness. Certainly both require the same mindset to ensure – rather than thinking merely “how will this work”, a quality-focused person will also, or perhaps alternately think: “how might this be breakable”. From this simple change in thinking flows several important approaches

  • Constraint-based thinking (as opposed to solution based thinking): allows an architect/developer to conceive of the set of possible solutions, rather than an enumeration of solutions. By looking at constraints, a developer implements the lean principle of deciding as late as possible, with as full information as possible.
  • Test-First: As one thinks of how it might break, scenarios emerge that can form the basis of test cases. These cases form a sort of executable acceptance criteria
  • Lateral Thinking: The constraint+test approach starts to get people into a very different mode, where vastly different kinds of solutions show up. The creative exercise of trying to break something provides insights that can change the whole approach of the system.

 Schneier goes on to ponder 

This mindset is difficult to teach, and may be something you’re born with or not. But in order to train people possessing the mindset, they need to search for and find security vulnerabilities–again and again and again. And this is true regardless of the domain. Good cryptographers discover vulnerabilities in others’ algorithms and protocols. Good software security experts find vulnerabilities in others’ code. Good airport security designers figure out new ways to subvert airport security. And so on.  

 Here again – I think it’s possible to help people get a mind-set about quality, but some do seem to have a knack. It’s important to have some of these people on your teams, as they’ll disturb the waters and identify potential failure modes. These are going to be the ones who want to “mistake proof” (to borrow Toyota’s phrase) the system by writing more unit tests and other executable proofs of the system. But most importantly (and I can personally testify to this) it is critical that people just write more tests. It is a learned skill to start to think of “how might this fail” until it becomes a background mental thread, always popping up risk models.A related concept is Demmings’ “systems-thinking”, which, applied to software quality, causes one to start looking at whole ecosystems of error states. This is when fearless re-factoring starts to pay off, because the elimination of duplication allows one to catch classes of error in fewer and fewer locations, where they’re easier to fix. There are many and multifarious spin-off effects of this inverted questioning and the mindset it generates. Try it yourself. When you’re writing code, ask yourself how you might break it? What inputs, external state, etc. might cause it to fail, crash, or behave in odd ways. This starts to show you where you might have state leaking into the wild, or side-effects from excessively complex interactions in your code. So quality focus can start to improve not only the external perception of your product, but also its fitness to new requirements by making it more resilient and less brittle. Cleaner interactions and less duplication allow for much faster implementation of new features.I could go on, but I just wanted to convey this sense of “attitude” or “mindset,” over mere technique. Technique can help you get to a certain level, but you have to let it “click”, and the powerful questions can sometimes help.


Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Berteig
Upcoming Courses
View Full Course Schedule
Kanban for Product Owners (ML-KPO)
Online
C$495.00
Dec 7
2022
Details
Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Dec 12
2022
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1795.00
Dec 13
2022
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$495.00
Dec 14
2022
Details
Leading SAFe® with SA Certification (+FREE Scaling Workshop) (LSAFE)
Online
C$1395.00
Dec 14
2022
Details
Kanban Systems Improvement® (KSI) [Virtual Learning]
Online
C$1795.00
Dec 15
2022
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1795.00
Dec 15
2022
Details
Team Kanban Practitioner® (TKP)
Online
C$1195.00
Dec 20
2022
Details
Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Dec 20
2022
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Dec 20
2022
Details
Win as a Manager (ML-WAAM)
Online
C$895.00
Dec 21
2022
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Dec 23
2022
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Jan 6
2023
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$495.00
Jan 10
2023
Details
Kanban for Product Owners (ML-KPO)
Online
C$495.00
Jan 11
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jan 16
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jan 16
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1525.75
Jan 17
2023
Details
Win as a Manager (ML-WAAM)
Online
C$895.00
Jan 19
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jan 20
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jan 20
2023
Details
Kanban System Design® (KMPI)
Online
C$1525.75
Jan 24
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1525.75
Jan 24
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jan 26
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jan 26
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jan 27
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jan 27
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Feb 3
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Feb 3
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Feb 6
2023
Details
Kanban Systems Improvement® (KSI) [Virtual Learning]
Online
C$1525.75
Feb 7
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Feb 13
2023
Details
Win as a Manager (ML-WAAM)
Online
C$895.00
Feb 16
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Feb 17
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Feb 27
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Feb 27
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Mar 3
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Mar 6
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Mar 10
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Mar 17
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Mar 21
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Mar 24
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Mar 31
2023
Details
Real Agility Management Track - Practitioner I (RA-MT-LA)
Online
C$7950.00
Apr 3
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 4
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 14
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 17
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 21
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 25
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 28
2023
Details