Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Process Management

SPaMCAST 345 – Cognitive Biases, QA Corner, TameFlow

 www.spamcast.net

http://www.spamcast.net

Listen Now

Subscribe on iTunes

The Software Process and Measurement Cast 345 features our essay on Cognitive Biases and two new columns. The essay on cognitive bias provides important tools for anyone that works on a team or interfaces with other people! A sample for the podcast:

“The discussion of cognitive biases is not a theoretical exercise. Even a relatively simple process such as sprint planning in Scrum is influenced by the cognitive biases of the participants. Even the planning process itself is built to use cognitive biases like the anchor bias to help the team come to consensus efficiently. How all the members of the team perceive their environment and the work they commit to delivering will influence the probability of success therefore cognitive biases need to be understood and managed.”

The first of the new columns is Jeremy Berriault’s QA Corner.  Jeremy’s first QA Corner discusses root cause analysis and some errors that people make when doing root cause analysis. Jeremy, is a leader in the world of quality assurance and testing and was originally interviewed on the Software Process and Measurement Cast 274.

The second new column features Steve Tendon discussing his great new book, Hyper-Productive Knowledge Work Performance.  Our intent is to discuss the book chapter by chapter.  This is very much like the re-read we do on blog weekly but with the author.  Steve has offered the SPaMCAST listeners are great discount if you use the link shown above.

As part of the chapter by chapter discussion of Steve’s book we are embedding homework questions.  The first question we pose is “Is the concept of hyper-productivity transferable from one group or company to another?” Send your comments to spamcastinfo@gmail.com.

Call to action!

Reviews of the Podcast help to attract new listeners.  Can you write a review of the Software Process and Measurement Cast and post it on the podcatcher of your choice?  Whether you listen on ITunes or any other podcatcher, a review will help to grow the podcast!  Thank you in advance!

Re-Read Saturday News

The Re-Read Saturday focus on Eliyahu M. Goldratt and Jeff Cox’s The Goal: A Process of Ongoing Improvement began on February 21nd. The Goal has been hugely influential because it introduced the Theory of Constraints, which is central to lean thinking. The book is written as a business novel. Visit the Software Process and Measurement Blog and catch up on the re-read.

Note: If you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast.

Dead Tree Version or Kindle Version 

Next . . . The Mythical Man-Month Get a copy now and start reading! We will start in four weeks!

Upcoming Events

2015 ICEAA PROFESSIONAL DEVELOPMENT & TRAINING WORKSHOP
June 9 – 12
San Diego, California
http://www.iceaaonline.com/2519-2/
I will be speaking on June 10.  My presentation is titled “Agile Estimation Using Functional Metrics.”

Let me know if you are attending!

Also upcoming conferences I will be involved in include and SQTM in September. More on these great conferences next week.

Next SPaMCast

The next Software Process and Measurement Cast will feature our will interview with Jon Quigley.  We discussed configuration management and his new book Configuration Management: Theory, Practice, and Application. Jon co-authored the book with Kim Robertson. Configuration management is one of the most critical practices anyone building a product, writing a piece of code or working on a project with other must learn or face the consequences!

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

Re-Read Saturday: The Goal: A Process of Ongoing Improvement. Part 16

IMG_1249

As part of my day job I am often asked to help a team, project or department find a way to improve the value they deliver.  When dealing with knowledge work having a single, prescriptive path is rarely effective because even the most mundane product support work includes discovery and innovation. Once we have discovered a path it is important to step back and generalize the approach so that teams can use the process in a variety of scenarios.  I have found that developing a generalized approach is rarely as straight forward as changing the personal pronouns in the process to refer to another group. Regardless of this hard won realization, I still read posts and hear about people that are considering adopting best practices or procedures from other groups without tailoring.  Adopting a process, procedure or even a tool using an untailored, out of the box approach is rarely a good idea in knowledge work.  Alex and his team continue to search for a generalized approach that can be used to transform the entire division

Previous Installments:

Part 1       Part 2       Part 3      Part 4      Part 5 
Part 6       Part 7      Part 8     Part 9      Part 10
Part 11     Part 12      Part 13    Part 14    Part 15

 

Chapter 37. Alex and his team continue their daily meetings do discover the answer to the question “What are the techniques needed for management?” In Chapter 36 the team had settled on a generalized five step process which was:

  1. Find the bottleneck,
  2. Exploit the bottleneck,
  3. Subordinate every other step to the bottleneck,
  4. Elevate the bottleneck, then
  5. Repeat if the bottleneck has been broken.

 

Ralph (computer guy) voices a concern that they really had not done step three.  After some discussion the team finds that the by constraining how work and material enter the process they really had subordinated all of the steps in the process to the bottlenecks.  Remember that the work and material entering the process had been constrained so the bottlenecks were 100% utilized (no more, no less).  During the discussion, Stacey (materials) recognized that the earlier red/yellow card approach the team had used to control the flow of work into the bottlenecks was still in place and was the cause of the problems she had been observing (Chapter 36). In order to deal with the problems caused by earlier red/yellow card approach and to keep everyone busy, Stacey admitted to have been releasing extra work into the process therefore building excess inventory of finished goods.  The back of the envelope calculations showed that the plant now had 20% extra capacity therefore they needed more orders to keep the plant at maximum capacity.  Alex decides go see Johnny Jons (sales manager) to see if they can prime the sales pump.

These observations led the team to the understanding that every time they recycled through the process they should have re-questioned and revalidated EVERY change they had previously made. The inertia of thinking something will work because it has in the past or because it has for someone else is often not your friend in process improvement!

Chapter 38. Jons, Alex, Lou (plant controller), Ralph and one of Jons more innovative salesmen meet at headquarters to discuss where they can come up with 10 million dollars of additional orders.  During the discussion it comes to light that Jons has a potential deal that he about to reject because the prices are well below standard margins. Alex points out that since the plant has excess capacity the real cost to produce the product is far lower than Jons is assuming (labor and overhead are already sunk costs). The plant could take the order and make a huge profit.  Alex and his team convince Jons to take the order if the potential client will commit to a one year deal.  They further sweeten the deal by committing to a quick deliveries (something other companies can’t emulate) in order to avoid starting a price war.  Jons agrees to accept the order as the potential client is well outside of the company’s standard area of distribution therefore will not impact the margins they getting on other orders.  On the way back to the plant Alex, Lout and Ralph reflect that they had just seen the same type of inertia that the team discovered the previous day in their process improvement approach and that Alex’s new role in changing the whole division will need to address even more organizational inertia.

Later Alex and Julie (wife) reflect that the key to the management practices Alex is searching for lie in the application of the scientific method.  Instead of collecting a lot of data and making inferences, the approach Johan had taken begins with a single observation, develops a hypothesis, leverages if-then relationships and then tests those relationships.  Alex searches popular scientific books for inspiration to his management questions.  When they discuss the topic again, Julie, who has continued to read the Socratic Dialogs, points out that they follow the same if-then pattern that Alex has described as Johan’s approach.

Re-Read Saturday Notes:

  1. I anticipate that the re-read of The Goal will conclude in two weeks with part 18. Our next book will be The Mythical Man-Month (I am buying a new copy today so if you do not have a copy . . . get a copy today and please use this Man-Month).
  2. Remember that the summary of previous entries in the re-read of The Goal have been shifted to a new page (here).
  3. Also, if you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast. Dead Tree Version or Kindle Version

 


Categories: Process Management

Traffic Light Measurement Indicators – Not All Lights Are Green

Red Light, Green Light

Red Light, Green Light

One of the most common indicators used in measurement and status report are traffic light indicators.  Traffic light indicators have been adopted because they are easy to recognize, represent complex information in a palatable manner and indicators are easy to explain.  The traffic light is elegant in its simplicity; however, that simplicity can also be its undoing. There three critical issues that traffic lights often exhibit which reduce their usefulness.

  1. Traffic light indicators obscure nuances and trends. Traffic light indicators generally use the simple green, yellow and red scale (good to bad). The indicator can only be set to one of those states, and there is no in-between (no orange or greenish yellow). HOWEVER, project status is rarely that cut and dried. For example, how would the indicator be set if a project exhibits serious threatening risks but the stakeholders currently satisfied with progress? Regardless of whether the indicator was set to red or yellow, much of the nuance of the situation would be lost. In addition, the traffic light indicator could not show whether the risks were being mitigated or threatening to become issues.
  2. Traffic light Indicators can generate poor personal and team behaviors. One of the most common problems observed with the usage of traffic light indicators is sticky statuses. A status is green or yellow, then seems to suddenly turn yellow or red overnight. The change from one color to another typically surprises management and stakeholders.  The change of color/status is often resisted because a change is viewed as a failure since there is no mechanism to provide a warning making the change is resisted. A second common problem is that making the indicator change becomes the project leader or team’s most important goal. When the metric becomes the goal, individuals and teams can be incented into trying to game of the metric which removes the focus from the customer.
  3. Traffic light indicators can lead to users of the indicator losing track of how it was calculated. Any high-level indicator, like a traffic light indicator, is a synthesis of many individual measures and metrics. Meg Gillikin, Deloitte Consulting, suggests “that you should have definitions of what each state means with specifics.”  The users of the indicator need to understand how it is set and the factors that go into setting the metric.  Lack of understand of any indicator can lead managers into making poor decisions…

Dácil Castelo, Leda MC, sums up the use of traffic light indicators, “The use of red, green and yellow provides a quick, visual summary of the status in a simple and easy way (everyone knows what a traffic light is). On the other hand, easy to understood doesn’t mean easy to calculate nor necessarily useful for the user.” Remember that with any indicator there is a basic issue IF an indicator doesn’t actually help teams and leaders to delivery of value it will be view as overhead


Categories: Process Management

Traffic Light Indicators for Metrics and KPIs

Stop on Red!

Stop on Red!

One of the most common indicators used in measurement and status report are traffic light indicators.  Traffic light indicators are most commonly shown as a set of red, yellow and green lights.  The metaphor draws from the nearly ubiquitous traffic light seen at nearly every intersection.  Traffic light indicators are part family of indicators of that combine indices and scales. Indices are typically used when a single measure or metric does not tell the story. An index reflects a composite of measures. Measures and/or metrics are averaged together or combined using complex mathematics.  The index is then transposed onto a scale so that it can be interpreted and used.  For example, wind chill is an index that combines temperature and wind speed into a temperature perceived by the skin. Wind chill once calculated is shown on a temperature scale. As a project status indicator, a traffic light indicator typically reflects a synthesis of many attribute.  The traffic light uses a simple scale in which red means trouble; yellow means caution and green means clear sailing. Traffic lights are adopted for three highly related reasons.

  1. Traffic lights are easy to recognize. The traffic light is a common symbol that every driver has been taught to recognize. Attaching a traffic light instantly indicates that a summary of status is being communicated.
  2. Traffic lights provide a consolidated view of complex attributes. The traffic light scale is a simple metaphor with three possible indications of overall performance.  Even in a simple project attributes such as budget, client satisfaction and risk must be synthesized into single perception of status that can be communicated. Traffic light indicators force a synthesized view.
  3. Traffic lights are easy to explain. Once an organization reaches a consensus on the business rules that set a traffic light indictor to red, yellow or green, is easy to explain. Red is bad and requires immediate action, yellow means caution, performance issues require mitigation and green mean business as usual.   Paul Byrnes, CMMI Lead Appraiser, when asked why people are drawn to traffic lights noted that “colors are easy…except for people that can’t see them… .”

 

Karl Jentzsch, a colleague at David Consulting Group summarized the case for traffic light indicators as “the appeal is that it provides an easily manageable number of ‘buckets’ to drop things into where the categorical distinctions are still fairly clear and inherently understood – good/go (green), bad/no (red), and in between (yellow).”

I often hear traffic lights defended with the statements like “we have always used traffic lights” and “or they are required by the PMO.” These are excuses that reflect an abrogation of thought and responsibility. It is too easy to succumb the simplicity of the indicator without reflecting on all the hard work and analysis needed to set the indicator. Typically this should be a lot of math and analysis to set the traffic light to red, yellow or green.  The math and the analysis is where the real magic happens and requires thought and understanding. As an indicator, the traffic light is elegant in its simplicity; however that simplicity can also be its undoing.


Categories: Process Management

Microservices architecture principle #6: One team is responsible for full life cycle of a Micro service

Xebia Blog - Tue, 06/02/2015 - 20:08

Microservices are a hot topic. Because of that a lot of people are saying a lot of things. To help organizations make the best of this new architectural style Xebia has defined a set of principles that we feel should be applied when implementing a Microservice Architecture. Today's blog is the last in a series about our Microservices principles. This blog explains why a Microservice should be the responsibility of exactly one team (but one team may be responsible for more services).

Being responsible for the full life cycle of a service means that a single team can deploy and manage a service as well as create new versions and retire obsolete ones. This means that users of the service have a single point of contact for all questions regarding the use of the service. This property makes it easier to track changes in a service. Developers can focus on a specific area of the business they are supporting so they will become specialists in that area. This in turn will lead to better quality. The need to also fix errors and problems in production systems is a strong motivator to make sure code works correctly and problems are easy to find.
Having different teams working on different services introduces a challenge that may lead to a more robust software landscape. If TeamA needs a change in TeamB’s service in order to complete it’s task, some form of planning has to take place. Both teams have to cater for slipping schedules and unforeseen events that cause the delivery date of a feature to change. However, depending on a commitment made by another team is tricky; there are lots of valid reasons why a change may be late (e.g. production issues or illness temporarily reduces a teams capacity or high priority changes take precedence). So TeamA may never depend on TeamB to finish before the deadline. TeamA will learn to protect its weekends and evenings by changing their architecture. Not making assumptions about another teams schedule, in a Microservice environment, will therefore lead to more robust software.

Microservices architecture principle #6: One team is responsible for full life cycle of a Micro service

Xebia Blog - Tue, 06/02/2015 - 20:08

Microservices are a hot topic. Because of that a lot of people are saying a lot of things. To help organizations make the best of this new architectural style Xebia has defined a set of principles that we feel should be applied when implementing a Microservice Architecture. Today's blog is the last in a series about our Microservices principles. This blog explains why a Microservice should be the responsibility of exactly one team (but one team may be responsible for more services).

Being responsible for the full life cycle of a service means that a single team can deploy and manage a service as well as create new versions and retire obsolete ones. This means that users of the service have a single point of contact for all questions regarding the use of the service. This property makes it easier to track changes in a service. Developers can focus on a specific area of the business they are supporting so they will become specialists in that area. This in turn will lead to better quality. The need to also fix errors and problems in production systems is a strong motivator to make sure code works correctly and problems are easy to find.
Having different teams working on different services introduces a challenge that may lead to a more robust software landscape. If TeamA needs a change in TeamB’s service in order to complete it’s task, some form of planning has to take place. Both teams have to cater for slipping schedules and unforeseen events that cause the delivery date of a feature to change. However, depending on a commitment made by another team is tricky; there are lots of valid reasons why a change may be late (e.g. production issues or illness temporarily reduces a teams capacity or high priority changes take precedence). So TeamA may never depend on TeamB to finish before the deadline. TeamA will learn to protect its weekends and evenings by changing their architecture. Not making assumptions about another teams schedule, in a Microservice environment, will therefore lead to more robust software.

Using Lines of Code as a Software Size Measure - New Lecture Posted

10x Software Development - Steve McConnell - Tue, 06/02/2015 - 18:08

I've posted this week's lecture in my Understanding Software Projects series at https://cxlearn.com. Most of the lectures that have been posted are still free. Lectures posted so far include:  

0.0 Understanding Sofware Projects - Intro
     0.1 Introduction - My Background
     0.2 Reading the News

1.0 The Software Lifecycle Model - Intro
     1.1 Variations in Iteration 
     1.2 Lifecycle Model - Defect Removal

2.0 Software Size
     2.05 Size - Comments on Lines of Code (New)
     2.1 Size - Staff Sizes 
     2.2 Size - Schedule Basics 

Check out the lectures at http://cxlearn.com!

Understanding Software Projects - Steve McConnell

 

Holacracy and the Search for Agile Organization

Mike Cohn's Blog - Tue, 06/02/2015 - 15:00

I met Brian Robertson back when he was still the CEO of Ternary Software and experimenting with the ideas that have become Holacracy. You’ve probably heard of Holacracy by now. It’s a way of running organizations. But it’s a very different way of running organizations. It’s been written up in Forbes and Wired magazines. But it’s often poorly described and misunderstood. So, what better way for us to learn about it than from its primary developer, Brian Robertson, who has written this guest post for us. —Mike

Agile software development is truly a stark contrast to the machine-like predict-and-control methods of a waterfall approach. For better or worse, agile methods are also in stark contrast to the organizational leadership, management, and governance structures of modern day business, which — like waterfall approaches — rely on autocratic predict-and-control management and tend to fight change.

This clash often creates significant stress between agile teams and the rest of the organization — stress that can severely slow or even kill the shift to agile methods. For organizations that do manage to make agile stick in their software teams, interesting questions then arise like, “can we run the rest of our organization on similar principles?” and “what would it take to make our entire organization agile?”

Fortunately, there are emerging methods that do for entire organizations what agile has done for software teams. This post examines one approach, called Holacracy, which offers a complete system for achieving agility in all aspects of an organization.

While Holacracy is by no means the first attempt to take agile approaches outside of software teams, as The Economist points out, “Holacracy goes further in shaking up working practices than most [other] approaches.” Holacracy also has more traction than any other defined system: it is already being used by hundreds of companies around the world, including notable mentions like Zappos, the David Allen Company, and Medium.

Adam Pisoni, co-founder of Yammer, adds: “Just like agile development systems break work into sprints, Holacracy forces a company to revisit its rules, roles, objectives and authorities in short cycles. This prevents you from over-planning upfront. It also gives you the chance to re-evaluate your plans, direction and beliefs on a regular, frequent basis.”

So, what is Holacracy? Essentially, it’s a new way of running an organisation that removes power from a management hierarchy and distributes it across clear roles, which can then be executed autonomously, without a micromanaging boss. More specifically, Holacracy differs from the traditional management model in four ways:

  1. No more job descriptions
    In most companies each person has a single job description that is often imprecise, outdated and irrelevant to their day-to-day work. In Holacracy, people have multiple roles, often on different teams, and those role descriptions are constantly updated by the team actually doing the work. This allows people working in a Holacracy-powered company a lot more freedom to express their creative talents. It also means that the company can take advantage of those skills in a way it couldn’t before.

    Ev Williams, cofounder of Blogger, Twitter and Medium, puts it this way: “In the past, as my companies have grown, I’ve hired these amazing people, and I’ve felt like I was getting less and less of them as the company got bigger. Part of that was because they were in a particular area, and if they had ideas or concerns or perspectives that were relevant outside that area, it wasn’t clear what to do with them. Holacracy provides a very specific way where people are actually encouraged to bring this stuff up. You really take advantage of everybody’s perspectives and ideas.”

  2. No more delegated authority
    The agility that Holacracy provides comes directly from truly distributed authority. In traditional organisations, managers loosely delegate authority, but ultimately their decisions always trump those they manage and everybody knows it.

    In Holacracy, authority is truly distributed and decisions are made locally, by the individual closest to the front line. Teams are self-organised: they’re given a purpose, but they decide internally how to best reach it. In this way, Holacracy replaces the traditional hierarchy with a series of interconnected but autonomous teams (“circles” in Holacracy’s vernacular). And once a circle has distributed some responsibility or authority to one of its roles, whoever fills that role has a whole lot of power in that area -- power no one else can trump.

    This is very different than in most companies, where only the management has the kind of authority needed to make important decisions. In practice, this means that everyone in the company is asked to take the reins and become a leader of their roles, and, conversely, a follower of others’ roles.

  3. No more big re-orgs
    In traditional companies, the organisation chart gets revamped every few years. These cyclical ‘re-orgs’ are an attempt to keep up with the changing environment, but since they only occur every three to five years, they are almost always out of date. In Holacracy, the structure of the organisation is updated every month in every circle.

    Yammer co-founder Adam Pisoni says it this way, “Most startups believe in iteration of their products. Now they need to apply the same thinking to their organisations.” Holacracy is precisely this type of solution: a rapid and agile approach to organisational development, rather than the industrial-age approach of predict, plan, and then cross your fingers and hope that you’ve made the right prediction.

    With Holacracy, the definitions of the roles and the circles are not prescribed in advance, nor are they rigidly defined. Instead, Holacracy allows a company to evolve whatever organisational structure is most suited to its current environment. In this way, Holacracy doesn’t just help organisations become evolved – it helps them become evolutionary.

  4. No more office politics
    In most companies, things are done a certain way because “that’s how we’ve always done it”, and those implicit rules are hard to change. Often no one knows why those rules exist, who decided them, or who can change them. This makes distributing authority almost impossible, because there is no way to ensure that everyone is following the same set of rules. The traditional management hierarchy is based mostly on ‘people who get it’ promoting other ‘people who get it.’

In Holacracy, distributing authority is not just a matter of taking power out of the hands of a leader and giving it to someone else or even to a group. Rather, the seat of power shifts from the person at the top to an explicit process, which is defined in detail in a written document (called the Holacracy ‘constitution’). In fact, when an organisation adopts Holacracy, the very first step is having the CEO or current power-holder formally cede his or her power into its rule system, meaning that they are subject to the same rules as everyone else.

This shift from personal leadership to constitutionally derived power is central to Holacracy’s new paradigm. The transparency of the rules means that you no longer have to depend on office politics to get things done.

Conclusion: a better way of working?
Companies designed in the 20th century have very little capacity to evolve and adapt. They are subject to evolution’s process at the market level and may survive or die as a result, but they are rarely adaptive organisms themselves, at least on more than a superficial level.

“The key to doing better,” argues Oxford economist Eric Beinhocker,“is to ‘bring evolution inside’ and get the wheels of differentiation, selection, and amplification spinning within a company’s four walls.” Holacracy offers the possibility of doing just that: embedding an enhanced capacity to dynamically and continually evolve, within an organisation’s core DNA.

It helps create organisations that are fast, agile and succeed by pursuing their purpose, free from the tyranny of top-down planning or the time-consuming pursuit of consensus.

It’s not a silver bullet – it takes hard work and practice to make the shift into such a dramatically different way of organising, but those who see and experience it in action are excited about its results. In the words of David Allen, author of "Getting Things Done" and a business leader with years of Holacracy experience in his own company, “Holacracy is not a panacea – it won’t resolve all of an organisation’s tensions and dilemmas. But, in my experience, it does provide the most stable ground from which to recognise, frame, and address them.”

Pre-order Brian’s book, "Holacracy: The New Management System for a Rapidly Changing World" (released June 2nd) here: http://holacracybook.com/

You can also read the first chapter here:
http://holacracy.org/sites/default/files/images/holacracybook-ch1.pdf

Share your thoughts, reactions, and questions about Holacracy in the comments section of the blog. We'll choose two commentators at random and send them a free copy of Holacracy.

From Software Delivery to Software Creativity

From the Editor of Methods & Tools - Tue, 06/02/2015 - 13:04
This editorial was inspired by a quote from Mary and Tom Poppendieck’s book “Lean Mindset“. They wrote “What’s next is to stop thinking about software development as a delivery process and to start thinking of it as a problem-solving process, a creative process.” In many large companies, software development has often been traditionally considered as […]

Microservices principles #5: Best technology for the job over one technology for all

Xebia Blog - Mon, 06/01/2015 - 11:39

Microservices are a hot topic. Because of that a lot of people are saying a lot of things. To help organizations make the best of this new architectural style Xebia has defined a set of principles that we feel should be applied when implementing a Microservice Architecture. Over the next couple of days we will cover each of these principles in more detail in a series of blog posts.
In this blog we cover: “Best technology for the job over one technology for all”

A common benefit of service based (and loosely coupled) architectures is the possibility to choose a different technology for each service. Even though this concept isn’t new, it’s rarely applied. Often the reason for this seems to be that even though the services should operate independently they do share (parts of) the same stack. This is further fueled by an urge to consolidate all development under a single technology. Reasoning here usually being that developers become more interchangeable and therefore more valuable if everything runs on the same technology, which should be a good thing.

So, if this isn’t new territory why drag it up again? Why would a Microservices architecture merit changing an existing approach? The short answer is autonomy. The long(er) answer is that a Microservices Architecture does not try to centralize common (technological) functions in singleton-esque services. No, the focus of a Microsservices architecture is on service autonomy, centered around business capability and a Microservice can therefore implement its own stack.  This to make a Microservice easier to deploy on their own and removes dependencies on other services as much as possible.

But autonomous deployment isn’t the most important reason to consider technology on a per-service basis. The most important reason is the simple “use the best tool for the job”. Not all technology is created equal. This isn’t limited to the choice of programming language or even the framework. It applies to the whole stack including the data layer.

Instead of spending a significant sum to buy large, bloated, multipurpose middleware, consider lightweight, single purpose containers. Pick containers that run the tech you need. You don't need Java applications with a relational database for everything. Other languages, frameworks and even datastores exist that cater to specific needs. Think of other languages like Scala or Go, frameworks like Akka or Play and database alternatives that focus on specific needs like storing (and retrieving) geographical data.

The choice of stack also relates to the choices you can make for your application landscape. If you have existing components that work for you or if you have components you want to buy off the shelve, it’s a real benefit to not be limited by an existing stack. For example, if you have opted for a Windows-only environment you are limiting your options.

Concerns about maintaining such a diverse landscape should consider that a lot of complexity comes from trying to maintain a single stack for everything. Smaller and simpler stacks should be easier to maintain. And having a single operations team for all those different technologies doesn't sound like a good idea? You're right! If you still have separate development and operations teams it may also be time to revisit that strategy. The devops approach makes running the services a shared responsibility. This doesn’t happen overnight but it is also a reason why Microservices can be such a good fit for organizations that have adopted an Agile way of working and/or apply Continuous Delivery.

Finally giving your developers a broader toolset to play with should keep them engaged. The opportunity to work with more than one technology can be a factor in retaining and attracting talent.

SPaMCAST 344 – Susan Parente, Agile Risk Management

Software Process and Measurement Cast - Sun, 05/31/2015 - 22:00

Software Process and Measurement Cast 344 features our conversation with Susan Parente.  We talked about Agile risk management. Risk is not always discussed in polite Agile circles however Susan suggests that if you do not have a plan to address risk you are asking for pain for yourself and everyone around you.

Susan’s Bio

Susan Parente is a Principal Consultant at S3 Technologies, LLC and an Associate Professor at Post University. She is an author, mentor and teacher focused on project and risk management. Her experience is augmented by her Masters in Engineering Management with a focus in Marketing of Technology from George Washington University, DC, along with a number of professional certifications. Ms. Parente has 16+ years’ experience leading software and business development projects in the private and public sectors, including a decade of experience implementing IT projects for the DoD.

Contact Data:

Email: parente@s3-tec.com

Phone: 203-307-5246

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

Risk Management Resources: www.techriskmanager.com

Company website: www.s3-tec.com

Agile Risk Management LinkedIn Group:

https://www.linkedin.com/groups?mostRecent=&gid=4020498&trk=my_groups-tile-flipgrp

Call to action!

Reviews of the Podcast help to attract new listeners.  Can you write a review of the Software Process and Measurement Cast and post it on the podcatcher of your choice?  Whether you listen on ITunes or any other podcatcher, a review will help to grow the podcast!  Thank you in advance!

Re-Read Saturday News

The Re-Read Saturday focus on Eliyahu M. Goldratt and Jeff Cox’s The Goal: A Process of Ongoing Improvement began on February 21nd. The Goal has been hugely influential because it introduced the Theory of Constraints, which is central to lean thinking. The book is written as a business novel. Visit the Software Process and Measurement Blog and catch up on the re-read.

Note: If you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast.

Dead Tree Version or Kindle Version 

Next . . . The Mythical Man-Month Get a copy now and start reading! We will start in four weeks!

Upcoming Events

2015 ICEAA PROFESSIONAL DEVELOPMENT & TRAINING WORKSHOP
June 9 – 12 
San Diego, California
http://www.iceaaonline.com/2519-2/
I will be speaking on June 10.  My presentation is titled “Agile Estimation Using Functional Metrics.”

Let me know if you are attending!

Also upcoming conferences I will be involved in include and SQTM in September. More on these great conferences next week.

Next SPaMCast

The next Software Process and Measurement Cast will feature our will essay on Cognitive Bias.  The core of software development, enhancements and maintenance is people. Knowledge of cognitive biases can help us understand and predict team behaviors. Will will also have the first installment Jeremy Berriault’s QA Corner.  QA Corner is all about testing.

 

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 344 – Susan Parente, Agile Risk Management

Software Process and Measurement Cast - Sun, 05/31/2015 - 22:00

Software Process and Measurement Cast 344 features our conversation with Susan Parente.  We talked about Agile risk management. Risk is not always discussed in polite Agile circles however Susan suggests that if you do not have a plan to address risk you are asking for pain for yourself and everyone around you.

Susan’s Bio

Susan Parente is a Principal Consultant at S3 Technologies, LLC and an Associate Professor at Post University. She is an author, mentor and teacher focused on project and risk management. Her experience is augmented by her Masters in Engineering Management with a focus in Marketing of Technology from George Washington University, DC, along with a number of professional certifications. Ms. Parente has 16+ years’ experience leading software and business development projects in the private and public sectors, including a decade of experience implementing IT projects for the DoD.

Contact Data:

Email: parente@s3-tec.com

Phone: 203-307-5246

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

Risk Management Resources: www.techriskmanager.com

Company website: www.s3-tec.com

Agile Risk Management LinkedIn Group:

https://www.linkedin.com/groups?mostRecent=&gid=4020498&trk=my_groups-tile-flipgrp

Call to action!

Reviews of the Podcast help to attract new listeners.  Can you write a review of the Software Process and Measurement Cast and post it on the podcatcher of your choice?  Whether you listen on ITunes or any other podcatcher, a review will help to grow the podcast!  Thank you in advance!

Re-Read Saturday News

The Re-Read Saturday focus on Eliyahu M. Goldratt and Jeff Cox’s The Goal: A Process of Ongoing Improvement began on February 21nd. The Goal has been hugely influential because it introduced the Theory of Constraints, which is central to lean thinking. The book is written as a business novel. Visit the Software Process and Measurement Blog and catch up on the re-read.

Note: If you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast.

Dead Tree Version or Kindle Version 

Next . . . The Mythical Man-Month Get a copy now and start reading! We will start in four weeks!

Upcoming Events

2015 ICEAA PROFESSIONAL DEVELOPMENT & TRAINING WORKSHOP
June 9 – 12 
San Diego, California
http://www.iceaaonline.com/2519-2/
I will be speaking on June 10.  My presentation is titled “Agile Estimation Using Functional Metrics.”

Let me know if you are attending!

Also upcoming conferences I will be involved in include and SQTM in September. More on these great conferences next week.

Next SPaMCast

The next Software Process and Measurement Cast will feature our will essay on Cognitive Bias.  The core of software development, enhancements and maintenance is people. Knowledge of cognitive biases can help us understand and predict team behaviors. Will will also have the first installment Jeremy Berriault’s QA Corner.  QA Corner is all about testing.

 

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 344 – Susan Parente, Agile Risk Management

 www.spamcast.net

http://www.spamcast.net

Listen Now

Subscribe on iTunes

Software Process and Measurement Cast 344 features our conversation with Susan Parente.  We talked about Agile risk management. Risk is not always discussed in polite Agile circles however Susan suggests that if you do not have a plan to address risk you are asking for pain for yourself and everyone around you.

Susan’s Bio

Susan Parente is a Principal Consultant at S3 Technologies, LLC and an Associate Professor at Post University. She is an author, mentor and teacher focused on project and risk management. Her experience is augmented by her Masters in Engineering Management with a focus in Marketing of Technology from George Washington University, DC, along with a number of professional certifications. Ms. Parente has 16+ years’ experience leading software and business development projects in the private and public sectors, including a decade of experience implementing IT projects for the DoD.

Contact Data:

Email: parente@s3-tec.com

Phone: 203-307-5246

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

Risk Management Resources: www.techriskmanager.com

Company website: www.s3-tec.com

Agile Risk Management LinkedIn Group:

https://www.linkedin.com/groups?mostRecent=&gid=4020498&trk=my_groups-tile-flipgrp

Call to action!

Reviews of the Podcast help to attract new listeners.  Can you write a review of the Software Process and Measurement Cast and post it on the podcatcher of your choice?  Whether you listen on ITunes or any other podcatcher, a review will help to grow the podcast!  Thank you in advance!

Re-Read Saturday News

The Re-Read Saturday focus on Eliyahu M. Goldratt and Jeff Cox’s The Goal: A Process of Ongoing Improvement began on February 21nd. The Goal has been hugely influential because it introduced the Theory of Constraints, which is central to lean thinking. The book is written as a business novel. Visit the Software Process and Measurement Blog and catch up on the re-read.

Note: If you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast.

Dead Tree Version or Kindle Version 

Next . . . The Mythical Man-Month Get a copy now and start reading! We will start in four weeks!

Upcoming Events

2015 ICEAA PROFESSIONAL DEVELOPMENT & TRAINING WORKSHOP
June 9 – 12
San Diego, California
http://www.iceaaonline.com/2519-2/
I will be speaking on June 10.  My presentation is titled “Agile Estimation Using Functional Metrics.”

Let me know if you are attending!

Also upcoming conferences I will be involved in include and SQTM in September. More on these great conferences next week.

Next SPaMCast

The next Software Process and Measurement Cast will feature our will essay on Cognitive Bias.  The core of software development, enhancements and maintenance is people. Knowledge of cognitive biases can help us understand and predict team behaviors. Will will also have the first installment Jeremy Berriault’s QA Corner.  QA Corner is all about testing.

 

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

Re-Read Saturday: The Goal: A Process of Ongoing Improvement. Part 15

IMG_1249

The idea of continuous process has been part of the business landscape in one form or another since the beginning of time. The leaders of the Total Quality Movement of the late 1980s, such as Juran, Deming and Crosby, certainly hammered the need for continuous change home as US business refocused on product quality. Unfortunately in many cases, the message suffered from two interpretation problems. The first was that process improvement was implemented as a focus on controlling and reducing costs, rather than on increasing process throughput. Secondly, many process improvement programs focused on the one big change rather than finding a generalized process that could continuously generate improvement. Finding and implementing a repeatable process requires culture change and long-term thinking, which are hard to implement. Paraphrasing W. Edwards Deming, we will need constancy of purpose to make continuous process improvement payoff, but with that constancy of purpose we won’t need a single overwhelming change. Alex and his team are recognizing that finding a generalized, repeatable process is not easy.

Part 1       Part 2       Part 3      Part 4      Part 5 
Part 6       Part 7       Part 8     Part 9      Part 10
Part 11     Part 12      Part 13    Part 14

Chapter 35. Alex and his team reconvene thier meeting to discover the answer to question “What are the techniques needed for management?”  The team spends the time trying to determine how to reveal the the essential steps that are needed to make change happen in a repeatable fashion.  Goldblatt describes this concept as the “intrinsic order.” This chapter reflects a struggle to find a generalized order or approach that can be used as management structure changes in the plant or to generate change in the other plants that will be reporting to Alex. The meeting ends in frustration but with an agreement to try again the next day.

Chapter 36. Stacey, the material manager, reframes the conversation by asking, “What is our goal as a manager?” In the past the managers had been charged with generating ongoing process improvements. Organizationally, formal process improvement projects were focused on reducing operating expenses, whereas Johan had led Alex and his team to change their focus to throughput. Reducing operating expense went from the most important goal to a distant third place behind throughput and inventory control. This refocusing was tied directly to the goal of increasing profit by increasing plant revenue.

By refocusing the discussion on the goal of process improvement in the plant, the team is able to find a generalized process. It is:

  1. Find the bottleneck in the flow of work.
  2. Decide how to “exploit” the bottleneck (make sure you maximize the flow through the bottleneck).
  3. Subordinate every other step to the bottleneck (only do the work the bottleneck can accommodate).
  4. Elevate the bottleneck (increase the capacity of the bottleneck).
  5. If the bottleneck has been broken repeat the process (a bottleneck is broken when the step has excess capacity).

As a test, Alex and his team cycle through the changes they made. Each change Alex and his team made to the flow of work, changed the nature of the bottleneck, which meant that the team had to cycle through the process again and again to continue to generate improvements. Each change Alex and his team had made used the same process which proved that had found a repeatable process to generate continuous process improvement. Before the team breaks up, it is suggested that the word bottleneck can be re-stated as constraint. A constraint a slightly broader concept and represents an obstacle to an organization achieving its goal whereas a bottleneck refers to a resource with capacity equal or less than the demand placed on it.  In this context not having enough sales orders to maximize the flow through plant would represent a constraint not a bottleneck.

Re-Read Saturday Notes:

  1. I anticipate that the re-read of The Goal will conclude in three weeks with part 18. Our next book will be The Mythical Man-Month (if you do not have a copy . . . get a copy today).
  2. Remember that the summary of previous entries in the re-read of The Goalhave been shifted to a new page (here).
  3. Also, if you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast. Dead Tree Versionor Kindle Version

Categories: Process Management

Software Development Conferences Forecast May 2015

From the Editor of Methods & Tools - Fri, 05/29/2015 - 15:05
Here is a list of software development related conferences and events on Agile project management ( Scrum, Lean, Kanban), software testing and software quality, software architecture, programming (Java, .NET, JavaScript, Ruby, Python, PHP) and databases (NoSQL, MySQL, etc.) that will take place in the coming weeks and that have media partnerships with the Methods & […]

Microservices architecture principle #4: Asynchronous communication over synchronous communication

Xebia Blog - Fri, 05/29/2015 - 13:37

Microservices are a hot topic. Because of that a lot of people are saying a lot of things. To help organizations make the best of this new architectural style Xebia has defined a set of principles that we feel should be applied when implementing a Microservice Architecture. Over the next couple of days we will cover each of these principles in more detail in a series of blog posts.
This blog explains why we prefer asynchronous communication over synchronous communication

In a previous post in this series we explained that we prefer autonomy of Microservices over coordination between Microservices. That does not imply a Microservices landscape with all Microservices running without being dependent on any other Microservice. There will always be dependencies, but we try to minimise the number of dependencies.  Once you have minimised the number of dependencies, how should these be implemented such that autonomy is maintained as much as possible? Synchronous dependencies between services imply that the calling service is blocked and waiting for a response by the called service before continuing it's operation. This is tight coupling, does not scale very well, and the calling service may be impacted by errors in the called service. In a high available robust Microservices landscape that is not preferable. Measures can be taken (think of things like circuit breakers) but it requires extra effort.

The preferred alternative is to use asynchronous communication. In this pattern the calling service simply publishes it's request (or data) and continues with other work (unrelated to  this request). The service has a separate thread listening for incoming responses (or data) and processes these when they come in. It is not blocking and waiting for a response after it sent a request, this improves scalability. Problems in another service will not break this service. If other services are temporarily broken the calling service might not be able to complete a process completely, but the calling service is not broken itself. Thus using the asynchronous pattern the services are more decoupled compared to the synchronous pattern and which preserves the autonomy of the service .

Biases Affecting Perception and Decision Making

What you see is dependent on what you expect.

What you see depends on what you expect.

Cognitive biases are a pattern of behavior that reflects a deviation in judgment that occurs under particular situations. Biases develop as filters or shortcuts that help us perceive information quickly in a manner that turns out to be beneficial to a decision-making process. Biases that help us recognize patterns helped early humans stay alive by recognizing predators. The shortcut kept our ancestors alive even if there were false positives (you can survive lots of false positives, but you aren’t likely to survive a false negative). Project teams (Agile or not) use or fall prey to a wide range of biases that affect perceptions and decisions. A sample of common biases that affect project teams in this category include:

Anchor bias refers to the tendency to rely heavily on one piece of information when making decisions. This bias is often seen when early estimates for a project or a tasks are made. The instant they are placed on the table they become a reference point to which all changes will be compared.

Clustering illusion (or clustering bias) is the tendency to see patterns in clusters or streaks of in a smaller sample of data inside larger data sets. For example, a team I recently worked with had an average velocity of 30 story points per sprint (ranged between 20 – 36) had three sprints in a row that delivered 40+ story points. While nothing significant had changed with how the team was working, outsiders saw a pattern and believed something out of the ordinary was occurring. (FYI – if there is no statistical significance to the data what we are seeing is “common cause” variance.)

The curse of knowledge bias generates a filter that blocks the ability think about a topic from a different and generally less informed perspective. In many cases being an expert on a topic makes it very difficult to see an out-of-the-box solution. This is one of the reasons significant changes in IT platforms or concepts come as new players enter the organization that have less experience with current tools and techniques. In a similar manner to the curse of knowledge, the status quo bias or the tendency to want things to stay relatively the same, creates a perception filter that helps the individual or team seek out and fixate data and concepts which makes them comfortable so they do not need to change.

An availability cascade causes a concept to become more and more plausible the more it is repeated publicly.  An availability cascade generates a self-reinforcing feedback loop. Perhaps that is why Pokemon became more popular the more it was shown on the Cartoon Network. Daniel Pink, author of To Sell Is Human, in a Salesforce.Com webinar on July 9th pointed out that repetition increases process fluency, which makes the repeated item seem to be more true through repetition. Sales, marketing and 24 hour news channels understand and use the availability cascade bias to great effect.

A final example of biases that affect behavior and perception is optimism bias. Optimism bias is the tendency to be overoptimistic about favorable outcomes. This bias is often exhibited in status reports or in promises made early in a project. These are generally not lies, but rather due to optimism bias we believe that we can deliver. Dr. Ricardo Validri in Software Process and Measurement Cast 84 suggests that optimism bias is one of major reasons IT personnel are poor estimators.

This is a sample of cognitive biases that affect how we perceive information and then how we make decisions. Each of the biases reflects some basic component of human psychology and has been found to be generally beneficial. However all biases can create blind spots. A good coach or leader will first be aware of his or her biases and then help the team understand their blind spots while not abandoning the shortcuts that can help us perceive what is important and make timely decisions.


Categories: Process Management

Team Sizes and Schedule Basics - New Lectures Posted

10x Software Development - Steve McConnell - Thu, 05/28/2015 - 19:19

I've posted this week's lecture in my Understanding Software Projects series at https://cxlearn.com. Most of the lectures that have been posted are still free. Lectures posted so far include:  

0.0 Understanding Sofware Projects - Intro

0.1 Introduction - My Background
     0.2 Reading the News

1.0 The Software Lifecycle Model - Intro
     1.1 Variations in Iteration 
     1.2 Lifecycle Model - Defect Removal

2.0 Software Size
     2.1 Size - Staff Sizes (New this week)
     2.2 Size - Schedule Basics (New this week)

Check out the lectures at http://cxlearn.com!

Understanding Software Projects - Steve McConnell

 

Microservices Architecture Principle #3: small bounded contexts over one comprehensive model

Xebia Blog - Wed, 05/27/2015 - 21:18

Microservices are a hot topic. To help organizations make the best of this new architectural style Xebia has defined a set of principles that we feel should be applied when implementing a Microservice Architecture. Over the next couple of days we will cover each of these principles in more detail in a series of blog posts. Today we discuss the Domain Driven Design (DDD) concept of "Bounded Context" and how it plays a major role in designing Microservices.

One of the discussion points around Microservices, since the term was coined in 2013, is how big (or rather, how small) a Microservice should be. Some people, such as Fred George, claim services should be small, maybe between 100-1000 lines of code (LoC). However, LoC is a poor metric for measuring software in general and even more so for determining the scope of a Microservice. Rather, when identifying the scope of our Microservices, we look at the functionality that a service needs to provide, and how the service relates to other services. Our aim is to design Microservices that are autonomous, ie. have a low coupling with other services, have well defined interfaces, and implement a single business capability, ie. have high cohesion.

A technique that can be used for this is "Context Mapping".  Via this technique we identify the various contexts in the IT landscape and their boundaries. The Context Map is the primary tool used to make boundaries between domains explicit. A Bounded Context encapsulates the details of a single domain, such as domain model, data model, application services, etc., and defines the integration points with other bounded contexts/domains. This matches perfectly with our definition of a Microservice: autonomous, well defined interfaces, implementing a business capability. This makes Context Mapping (and DDD in general) an excellent tool in the architects toolbox for identifying and designing Microservices.

Another factor in sizing our services is that we would like to have models that can "fit in your head", so as to be able to reason about them efficiently. Most projects define a single comprehensive model encompassing the full domain, as this seems natural, and appears easier to maintain as one does not have to worry about the interaction between multiple models, or translate from one context to the other.

For small systems this may be true, but for large systems the costs will start to outweigh the benefits: maintaining a single model requires centralization. Naturally the model will tend to fragment: a domain expert from the accounting domain will think differently about 'inventory' than a logistics domain expert, for example. It requires lots of coordinated efforts to disambiguate all terms across all domains. And worse, this 'unified vocabulary' is awkward and unnatural to use, and will very likely be ignored in most cases. Here bounded contexts will help again: they make clear where we can safely use the natural domain terms and where we will need to bridge to other domains. With the right boundaries and sizes of our bounded contexts we can make sure our domain models "fit in your head" and that we do not have to switch between models too often.

So maybe the best answer to the question of how big a Microservice should be is: it should have a well defined bounded context that will enable us to work without having to consider, or swap, between contexts.

Readers and Listeners!

Part of the enjoyment of publishing the Software Process and Measurement Blog and Podcast is interacting with my listeners, readers and interviewees!

Contests on the blog are one of the ways we provide the listener’s with a little bit of lagniappe. The Software Process and Measurement Cast 330 features an interview with Anthony Mersino. The interview about Agile, coaching, organizational change AND his new book Agile Project Management  provided great advice to the podcast listeners. In a great gesture,  Anthony sponsored a contest for copy of his book. The winner is Paul Laberge! Paul is a long time reader of the blog and listener to the podcast (and frequently writes to discuss ideas or to argue about cell phone operating systems). Here is a picture of Paul and his new book.

Untitled1

Paul, thank you for being part of both the podcast and the blog! Anthony, thank you for providing the book and the contest! Interested in doing a review Paul?

On another front, recently I attended the CMMI® Global Conference and met Hiroshi Kobayashi. Hiroshi is also a listener, reader and often comments on the blog. I find it incredible to meet people in person that I interact with on the podcast and blog. Interacting with members of the SPaMCAST community keeps me motivated. Here is a picture of Hiroshi and myself (thanks to Paul Byrnes for taking the picture).

Untitled

Hiroshi is a Senior Executive Manager of the CMMI Consulting Division at System Information Company in Japan. He is also PMI certified Project Management Professional and a Scrum Alliance Certified Scrum Master.

Hiroshi, I look forward to collaborating on the blog and podcast!

A message to all readers and listeners! If you are going to be at ICEAA in June 9 -12 in San Diego, please let me know or find me at the conference. I would like to me you in person, hear your story, talk about ideas, concepts and even the weather!

My sincere thanks to Paul, Hiroshi and ALL of my readers and listeners. Interacting with you enriches my blogging and podcasting experience and I hope it enriches yours!


Categories: Process Management