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

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

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

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

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 732
Software Development Blogs: Programming, Software Testing, Agile, Project Management
Skip to content

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

Methods & Tools

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

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

Robots bring business and IT together

Xebia Blog - Fri, 10/28/2016 - 13:46
Maybe you’ve already read the diary of one of our mBots, if not I encourage you to do so first! So, what was this day all about? How did we come to organise this and what did the participants learn? Changing teams As companies decide to adopt a more agile way of working, they also start

Systems Thinking: The Pros to Offset the Cons

The big (panoramic) picture.

The big (panoramic) picture.

In Systems Thinking: Difficulties we focused on the dark side of systems thinking.  But, systems thinking is a powerful framework for change agents. There are two primary reasons systems thinking has a tremendous impact:

  • Understanding Context
  • Value Focus

Making changes to processes and activities that you are directly involved with and then demonstrating the impact of that change is (relatively) easy. Making a change that has a demonstrable impact on the products and services delivered by the larger organization and then proving it is . . . hard.¬† It would be impossible without an understanding of the big picture. We’ve defined a system as a group of interacting, interrelated, and interdependent components that form a complex and unified whole. Missing from the definition is an outcome, for most organizations that output is a product or service (or multiples).¬† Taking a systems thinking perspective allows change agents to generate an understanding of how raw materials are taken into the system, transformed and delivered, which provides the context any potential change. ¬†Silos and departments can be transposed on the big picture to provide a map of the boundaries involved. ¬†Mapping boundaries helps to develop an understanding of complexity and more importantly it helps when planning any change. Boundaries identify who needs to be involved and who needs to buy-into a change. ¬†An understanding of the flow that work or product needs to take to reach the customer also provides information for identifying improvement opportunities. Changes to subsystems, steps or activities that are not on the path to delivery can‚Äôt impact products or services.¬† Value chain mapping would call the processes on the path to delivery ‚Äėcore processes‚Äô and those not on the path ‚Äėsupport‚Äô. Changes to support processes are important, generally for cost containment rather than to affect the product.¬† Having a systems thinking perspective ensures we know whether any opportunity has a chance at reaching our customers.

The second reason systems thinking is important is its focus on delivering value. Said differently, there is a focus on making a difference to the customers.  One of the more serious criticisms of many process improvement programs is that steps get optimized causing more problems (such as additional work-in-processes waiting for the next step).  The relentless focus of system thinking on what is delivered by the system helps to ensure that change opportunities are not just optimizations of individual steps that do not deliver an impact to the output of the systems. A second benefit to the focus on value is that the discussion of value and impact cuts through much of the resistance that boundaries can cause in organizations. Would you like to be the person that gets in the way of a change that delivers customer value . . . I think not.  More importantly than beating down resistance, organizational value provides a goal that helps builds bridges and that everyone in an organization can believe in.

Having a goal that everyone can rally around is critical when making any process improvement. Systems thinking provides a structure to see and consider the big picture while focusing on the one goal that most everyone in an organization can agree upon: value. I often use the metaphor of planting a flag on the top of a hill in a game of capture the flag to drive home the point of needing a goal. Systems thinking ensures that we plant the flag on the right hill.


Categories: Process Management

Systems Thinking: Difficulties

Boundaries, like fences are one potential difficulty.

Boundaries, like fences, are one potential difficulty.

Systems thinking is a powerful concept that can generate significant for value for organizations by generating more options. Dan and Chip Heath indicate that options are a precursor to better decisions in their book Decisive. Given the power of the concept and the value it can deliver, one would expect the concept to be used more. The problem is that systems thinking is not always straightforward.  The difficulties with using systems thinking fall into three categories.

  • Boundaries
  • Complexity
  • Day-to-Day Pressures

Organizational boundaries and their impact of the flow of both work and information have been a source of discussion and academic study for years.  Boundaries are a key tool for defining teams and providing a send of belonging; however, some boundaries not very porous. As noted in our articles on cognitive biases, groups tend to develop numerous psychological tools to identify and protect their members.  Systems, in most cases, cut across those organizational boundaries. In order to effectively develop an understanding of a system and then to affect a change to that system, members of each organizational unit that touches the system need to be involved (involvement can range from simple awareness to active process changes). When changes are limited due to span of control or a failure to see the big picture, they can be focused on parts of a process that, even if perfectly optimized, will not translate to the delivery of increased business value.  In a recent interview for SPaMcast, author Michael West provided examples of a large telecommunication company that implemented a drive to six sigma quality in its handsets, only to find out that pursuing the goal made the handset too expensive to succeed in the market. In this case the silos between IT, manufacturing and marketing allowed a change initiative to succeed (sort of) while harming the overall organization.

The second category is complexity.  Even simple systems are complex. Complexity can be caused by the breadth of a system.  For example, consider the relatively simple product of a lawn service.  How many processes and steps are required to attract and sign-up customers, then secure the equipment and employees to perform the job, schedule the service, actually deliver the service and then to collect payment? The simple system becomes more complex as we broaden the scope of our understanding.  Add in the impact of a variable like weather or an employee calling in sick, and things get interesting.  Really complicated systems, such as the manufacturing and sale of an automobile, can be quite mind-numbing in their complexity.  The natural strategy when faced with this level of complexity is to focus on parts of the overall system. This can lead to optimizations that do not translate to the bottom line. A second natural strategy for dealing with complexity is to develop models. All models are abstractions, and while abstractions are needed, you need to strike a balance so that the ideas generated from studying the model or results of experiments or pilots run against the model are representative of results in the real world.  For example, let’s say you build a 1/8 scale replica of a server farm.  The replica is a model that could be used to study how the servers would be placed or used to plan how they would be accessed for service. This would be a valid use of a model.  But if the model was placed in the actual server room and the observation used to jump to the conclusion that since the model fit, the server farm would fit, a mistake could quite possibly be made. Because of the complexity, we tend to focus on a part of system or to make abstractions. However, both can make it hard to think about the big picture needed to apply systems thinking.

The final difficulty with the use of systems thinking is the pressure of the day-to-day.  As I noted when I re-read The 7 Habits of Highly Effective People, the urgent and important issues of the day can easily overwhelm the important but not urgent. The use of systems thinking and the systemic changes identified through the use of the tool will generally fall into the important but not urgent category.  A person who is having a heart attack due to cholesterol-clogged arteries needs to deal with urgency of the attack before identifying and addressing their diet and other root causes. Leveraging systems thinking as a tool to address large-scale systemic issues is not a magic wand, rather a concept that will require time and effort to use.  If the organization is being overcome by day-to-day events, systems thinking will be difficult to use.  One technique that I have seen to deal with this scenario is to create a cross-functional, highly focused (tiger team) with a specific time box to start the process. This will require removing the team’s day-to-day responsibilities until the team meets its goal. This is a very difficult tactic to use as the people you would want on the team are generally the best at their job. This can potentially have a negatively impact organizational performance for a short period of time. You must consider the ROI.

The use of systems thinking is not for the faint of heart.  There are difficulties in applying the concept.  Boundaries, complexity and day-to-day pressures are the most significant, however there are others such as ensuring the team has system thinking training. Systems thinking can deliver a broad overall perspective and great value, but as a leader you must balance the difficulties with the benefits.


Categories: Process Management

Three New Books You Want to Read on Scaling, Strategy and Testing in Agile

Mike Cohn's Blog - Tue, 10/25/2016 - 15:00

I want to let you know about three great new books on agile you should read. Two of them are in the series I edit for Addison-Wesley; the third is by an author who previously wrote a book for that series.

Large-Scale Scrum by Larman and Vodde

Large-Scale Scrum” by Craig Larman and Bas Vodde is great for anyone looking to scale Scrum up to medium and large projects. It provides a contrast to the very heavyweight Scaled Agile Framework (SAFe), and “Large-Scale Scrum” comes with its own cutesy acronym, LeSS. In fact the subtitle of the book is “More with LeSS.”

The book defines two scaling models. First is standard LeSS, which Larman and Vodde say is typically used for projects with around five teams. It can certainly scale beyond there. But for much larger projects, the book also defines “LeSS Huge,” which the authors report having used on projects with over 1,000 people.

The book is organized as you might expect with chapters devoted to key Scrum topics such as the product owner, the product backlog, sprint planning, reviews and retrospectives, and so on.

I found the book to strike a perfect balance between being overly prescriptive and too general. You’ll leave the book with plenty of advice on how to scale a Scrum project. But you won’t leave feeling hamstrung by having too many rules placed on your teams.

In fact, the authors include a nice summary of LeSS and LeSS Huge rules at the end of the book, and it covers only three pages.

Developer Testing by Alexander Tarlinder

Early in my career as a programmer, I remember coming across the phrase, “You can’t test quality in.” I read this inan article that compared 1970s and 1980s U.S. automobile manufacturing to Japanese automobile manufacturing.

The author was saying the U.S. car manufacturers were producing cars of lower quality than their Japanese counterparts because U.S. car manufacturers were trying to test quality into their products. Only after the car was built would they test to see if it was high quality. If it wasn’t, they’d fix defects (say a poorly fitting door) to make the product higher quality.

This was in contrast to Japanese manufacturers who built quality into the process. A later colleague of mine referred to this by saying, “Quality is baked into our process.”

Quality is not something that can be added to a product. Trying to add quality after the product has been built would be like adding baking powder to a cake after the cake has been baked. It doesn’t work.

Alexander Tarlinder’s new book, “Developer Testing: Building Quality into Software,” teaches programmers how to bake or build quality right into the process. The book starts with fundamentals (what is unit testing?) but also delves deep into more advanced topics like testing with mock objects. Similarly, it adds to the debate about testing state vs. behavior.

The book comes in at just under 300 pages, but is encyclopedic in what it covers. This book is a must read for every programmer, even those who are already doing a great job at developer testing.

Strategize by Roman Pichler

Most agile processes are empty of any advice on forming a company or product strategy. Product backlogs or featurelists are just assumed to exist or to spring spontaneously from the mind of a product owner or key stakeholder. In his new book, “Strategize,” Roman Pichler fills this void in agile thinking.

Roman is a long-time Scrum trainer based in the UK. He has previously written books about the overall Scrum framework and about succeeding as a product owner.

In “Strategize,” Pichler covers how to form and then validate a strategy, including identifying the right audience for the product and delivering just the features they need. The book covers roadmapping, including addressing the unfortunate misconception that because a team is agile, they don’t need to know where they’re headed.

Pichler presents a very helpful roadmap selection matrix that helps identify what type of roadmap is appropriate for different types of projects. I’ve already put this to use in discussions with clients. And I’m becoming convinced that if a company had a bad experience with roadmapping in the past, it was likely because of doing the wrong type of roadmapping. This book’s roadmap selection matrix will fix that.

This book should be read by anyone involved in determining the future direction for a product or entire organization.

What Do You Think?

Which of these books are you going to read next? Or, if you’ve already read any, please share your thoughts in the comments below.

Software Development Conferences Forecast October 2016

From the Editor of Methods & Tools - Tue, 10/25/2016 - 14:02
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), DevOps and databases (NoSQL, MySQL, etc.) that will take place in the coming weeks and that have media partnerships with the Methods […]

Guest blog: in response to "The Five Belts of the Product Owner

Xebia Blog - Tue, 10/25/2016 - 12:37
This is a response to Chris Lukassen's excellent post titled, "The Five Belts of the Product Owner." If you haven't read it, my post won't make much sense, so go read it before you delve further into my post. Chris's post brought up many thoughts and feelings because it hit the intersection of two of

A day in the life of an mbot

Xebia Blog - Mon, 10/24/2016 - 16:44
Today, I managed to find a diary hidden on one of the mbots we have at the office. I couldn't see it in the user interface, but when I was doing some maintenance on the robot a simple 'ls -la' command in the terminal showed me this hidden content. It was so cute that I wouldn't

SPaMCAST 416 - Kirk Botula, Agility and Capability

Software Process and Measurement Cast - Mon, 10/24/2016 - 03:55

The Software Process and Measurement Cast features our interview with Kirk Botula on capability.  Kirk makes the argument that capability is crucial for organizational health and agility.

Kirk Botula is the CEO of the CMMI¬ģ Institute, the home of the globally-adopted capability improvement framework that guides organizations in high-performance operations. Botula is a global growth company executive whose career has been focused on advancing the common good through the commercialization of technology. Prior to CMMI Institute, Botula served as President of Confluence, a global financial technology firm with operations in North America, EMEA and Asia.

During his tenure, Confluence became the leading provider in its space achieving market share exceeding 70% in North America and 20% globally, while delivering the industry leading NPS of 40. Botula also served at BNY Mellon, Compunetix, and as a strategist to a variety of nonprofit and for-profit organizations. He has a BFA and MSIA from Carnegie Mellon University and lives in Pittsburgh with his wife and three daughters.

Reach out to Kirk at info@cmmiinstitute.com

 

Re-Read Saturday News

We continue the read/re-read of The Five Dysfunctions of a Team by Patrick Lencioni (published by Jossey-Bass).   As we move through the first part of the book we are being exposed to Lencioni’s model of team dysfunctions and a set of crises to illustrate the common problems that make teams into dysfunctional collections of individuals. Today we re-read the three sections titled Awareness, Ego and Goals.

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

Next SPaMCAST

The Software Process and Measurement Cast 417 will feature three columns from Steve Tendon, Jeremy Berriault and of course a new essay from the Software Process and Measurement Cast.

Shameless Ad for my book!

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

Categories: Process Management

SPaMCAST 416 ‚Äď Kirk Botula, Agility and Capability

SPaMCAST Logo

http://www.spamcast.net

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

The Software Process and Measurement Cast features our interview with Kirk Botula on capability.  Kirk makes the argument that capability is crucial for organizational health and agility.

Kirk Botula is the CEO of the CMMI¬ģ Institute, the home of the globally-adopted capability improvement framework that guides organizations in high-performance operations. Botula is a global growth company executive whose career has been focused on advancing the common good through the commercialization of technology. Prior to CMMI Institute, Botula served as President of Confluence, a global financial technology firm with operations in North America, EMEA and Asia.

During his tenure, Confluence became the leading provider in its space achieving market share exceeding 70% in North America and 20% globally, while delivering the industry leading NPS of 40. Botula also served at BNY Mellon, Compunetix, and as a strategist to a variety of nonprofit and for-profit organizations. He has a BFA and MSIA from Carnegie Mellon University and lives in Pittsburgh with his wife and three daughters.

Reach out to Kirk at info@cmmiinstitute.com

 

Re-Read Saturday News

We continue the read/re-read of The Five Dysfunctions of a Team by Patrick Lencioni (published by Jossey-Bass).   As we move through the first part of the book we are being exposed to Lencioni’s model of team dysfunctions and a set of crises to illustrate the common problems that make teams into dysfunctional collections of individuals. Today we re-read the three sections titled Awareness, Ego and Goals.

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

Next SPaMCAST

The Software Process and Measurement Cast 417 will feature three columns from Steve Tendon, Jeremy Berriault and of course a new essay from the Software Process and Measurement Cast.

Shameless Ad for my book!

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


Categories: Process Management

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

The Five Dysfunctions of a Team Cover

The book during unboxing!

Today we continue our re-read of the business novel, The Five Dysfunctions of a Team  by Patrick Lencioni (Jossey-Bass, Copyright 2002, 33rd printing). If you do not have a copy of the book, please buy a copy from the link above and read along. As we move through the first part of the book we are being exposed to Lencioni’s model of team dysfunctions and a set of crises to illustrate the common problems that make teams into dysfunctional collections of individuals.

Awareness

Next to the base of the five-stage model titled absence of trust (introduced in the section titled “The Speech”) ¬†Kathryn wrote the term invulnerability. People that have trust are willing to show their vulnerability to others on the team. Without trust, people put up a wall so they appear invulnerable which impedes communication and sharing need to create a functional team. ¬†Kathryn describes the next exercise that will help the group to demonstrate showing¬†vulnerability in a safe environment.

The exercise: Each person on the team will take five minutes to identify their single biggest strength and weakness related to their involvement at DecisionTech. Answers that with strengths that were over self-deprecating or included generic weaknesses were not allowed. The expectation is that each person will expose themselves to the rest of the group. Once the five minutes are up, each person will debrief with the rest of the group.

Nick began the debrief process.  He was open and honest in his strengths and weakness, and he listened to his teammate’s comments and critiques. It took trust for the group to be able to talk honestly about how they felt.

When Mikey shared, her strengths and weakness were shallow, showing a lack of trust in the group.  There was no interaction and comments from the rest the team.  Mikey’s lack of participation let the air out of the exercise.

Martin went last and noted that his weakness was that he gave the appearance of arrogance. This¬†sparked a discussion until Mikey squashed it noting that he would not be about to change without years of psychotherapy and that perhaps he was just hardwired to be arrogant. Kathryn didn’t call her on the remark, which was foreshadowed as a mistake.

Ego

Kathryn shifts the focus from the base of the model to the top of the pyramid. ¬† In the space at the top of the pyramid, she writes the phrase “Inattention to Results”. ¬†Dysfunctional teams fail to focus on collective results because individuals are honing their own egos and chasing individual status. ¬†Functional teams deliver collective results. Everyone has egos; however, on a team, the collective ego has to be greater than the individual ones. ¬†Over the years, I have watched Lebron James (power forward on the Cleveland Cavilers basketball team) mature and learn that an individual virtuoso can‚Äôt win if the team isn‚Äôt more than a collection of talented individuals. ¬†When the results of the overall team define¬†success, it is difficult for individual egos to get out of hand.

The book uses the example of Kathryn’s husband who coaches high school basketball.  He focuses on getting the team to be and play like a team which allows him to win consistently, even though the individuals are probably not as talented many individuals on the teams they play against.

One of the many important concepts in this section is that the goal of the leader is not to shepherd individual careers, but rather to get the most out of the team.

The section is capped off with a discussion of why sports provide a good training ground and metaphor for the concept of team.  The goal of a sport to unambiguously win. The score provides unambiguous proof of whether a team is successful. Scores also provide continuously updated and transparent feedback to everyone participating during the game so that there is no surprise when the game ends. Profit, which is the ultimate goal of for-profit organizations, is very difficult to use as a motivational tool because it is only known at the end of a reporting period. I classify profit as a rearview mirror type of measure; it tells you where have been but not necessarily where you are going. Profit is important, but a team needs other goals that more actionable. More actionable goals will be more like a score from a sporting event 

Goals

Goals are an important tool to focus attention and energy.  For a goal to be effective it needs to be actionable.  In an effort to identify more actionable goals, Kathryn leads another exercise.

Exercise: Break the group into subgroups of two or three people.  I recommend that the subgroups are cross-functional (note: in the book the subgroups are cross-functional because each person in the group is focused on different areas of the company). Have the subgroup propose a list of categories that the organization should have results-focused goals. In this exercise just create categories.  After the subgroups develop a list of categories, debrief and discuss with the whole group to develop a set of categories that represents a consensus amongst the whole team.

The DecisionTech executives identify 15 categories that they decide to measure on a monthly basis. As the discussion becomes more focused on the team‚Äôs day-to-day work, people fell back into their typical dysfunctional behavior. ¬†The book uses the example of the team discussing the public relationship category. ¬†In this category, goals and measures existed, however, most of the executive team either did not know they existed or didn’t understand them or . When the discussion got heated (with Mikey defending and deflecting criticism), the team shut down instead of getting to the crux of the problem. The section ends with Kathryn‚Äôs thought “so this is how it works.” We end on another cliffhanger!

Three quick take-ups:

  1.       Don’t let bad attitudes fester!
  2.       Team ego and success is more important than individual egos and success.
  3.       Goals should provide actionable feedback.

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

Week 1 ‚Äď Introduction through Observations

Week 2 ‚Äď The Staff through the End Run

Week 3 ‚Äď Drawing the Line though Pushing Back

Week 4 ‚Äď Entering Danger though Rebound

 


Categories: Process Management

Being An Agile Security Officer

Xebia Blog - Fri, 10/21/2016 - 13:31
Whenever I give a presentation, training, or just talk to security teams, it becomes clear that over the years a gap has been created between application security and development. A gap we created consciously and with intent and that became painfully visible with the introduction of Agile and DevOps. Suddenly exhaustive information security policies with

Systems Thinking: Putting Systems Thinking To Work In Process Improvement

Systems thinking helps to make sure process improvement see the big picture.

Systems thinking helps to make sure process improvement see the big picture.

Why isn’t systems thinking one of the first techniques any IT change agent reaches for?  Most change professionals have not been trained in applying systems thinking techniques because it is viewed as an engineering or academic practice. It provides a framework for the introduction of lean techniques, which have become popular to deliver the maximum business value. Lean provides tool and philosophy and systems thinking provides the breadth of scope to apply those tools.  Systems thinking provides process improvement with both a scope by defining what a system is and a business related goal for improvement, to improve the delivery of business value.

Affecting processes, systems and the environmental elements that are outside of the change agent’s control is difficult, requiring the development of influence and political capital outside of their comfort zone. For example, in an organization that is delivering a product that requires a hardware and software combination, a change that shortens the length of time needed to deliver the software may not impact the delivery time of the product if the hardware development does not keep pace. For another example, consider a set of process improvements meant to quicken the pace of requirements definition and evolution that feed into a classic stage gate for approval. The changes can be made moot by department boundaries within IT as easy as by processes and systems outside of IT. A few years ago, I observed a group of business analysts who embraced an iterative process for requirements elicitation, but still had to provide a single complete requirements definition document before the project could progress.  They had not been able to engage the owner of the stage gate process to fashion a scenario in which parts could be passed through the barrier as they were completed. Therefore little of the increased pace was transmitted to the overall process.

Process improvement begins by identifying opportunities. In order to use a systems thinking approach to process improvement we need to ensure that the boundary for process improvement is a whole system, a whole value chain, and provides the means to affect the output of the whole system. This helps ensure that any changes improve the overall performance of IT. One, simple approach I use to identify systems thinking process improvement opportunities begins by assembling a cross-functional team (or teams, for large supply-chain systems) that includes representatives with experience from the whole system Рbeginning to end.  This is similar to the process described in our discussion of value chain mapping. I facilitate the team through one or two sessions using a combination of affinity diagramming (brainstorming and mute-grouping) and mind mapping in order to identify the variables impacting the system.  Affinity diagramming is a technique of driving out and grouping large amounts of data though the use of seed questions and brainstorming, followed by team grouping exercise done without talking.  Mind mapping is then leveraged to mine the data for non-linear relationships and to prompt for completeness. Combining the two techniques, the cross functional team can take a holistic approach to making change. After we drive out the variables, I have the team work through building a desktop model to identify which variables the team feels will impact the ultimate performance of the system.  For the variables selected, I ask the team to identify trends underway in these variables and any external trends that impact these trends.  This generally requires a bit of research and the collection of performance data for the variables. Experimentation, like building mathematical models and process pilots, is used to determine if the identified variables will have a positive impact on the output of the system being studied.

Systems thinking is a powerful concept. However, the breadth of vision required to address even the small process improvements is intimating to many managers. So, they stay focused on their individual part of the process.  We have been taught that focusing on specific issues will help us improve what we do over time. Unfortunately, focusing on a narrow view of a complex system rarely provides enough information to affect overall customer experience or satisfaction. When improving development and maintenance processes, what really matters is that we deliver what we promised, when we promised and for what we promised. Then be in a position to do that as many times as required.  That last requirement means that our interactions, processes and people must be consumed in a holistic and sustainable manner. Building a backlog of process and human debt by focusing on steps rather than the whole does not deliver sustainable products.


Categories: Process Management

Software Development Linkopedia October 2016

From the Editor of Methods & Tools - Wed, 10/19/2016 - 11:02
Here is our monthly selection of knowledge on programming, software testing and project management. This month you will find some interesting information and opinions about the life and career of a software developer, technical debt, DevOps, software testing, metrics, microservices, API and mobile testing. Blog: Being A Developer After 40 Blog: Tech Debt Snowball ‚Äď […]

Systems Thinking: Habits Of A Systems Thinker

Sometimes you have to seek a little harder to understand the big picture.

Sometimes you have to seek a little harder to understand the big picture.

We should be guided by theory, not by numbers. – W.E. Deming

Many process improvement programs falter when, despite our best efforts, they don’t improve the overall performance of IT. The impact of fixing individual processes can easily get lost in the weeds; the impact overtaken by the inertia of the overall systems. Systems thinking is a way to view the world, including organizations, from a broad perspective that includes structures, patterns, and events.¬† Systems thinking is all about the big picture. Grasping the big picture is important when approaching any change program.¬† It becomes even more critical when the environment you are changing is complex and previous attempts at change have been less than successful. The world that professional developers operate within is complex, even though the goal of satisfying the projects stakeholders, on the surface, seems so simple. Every element of our work is part of a larger system that visibly and invisibly shapes our individual and organizational opportunities and risks.¬† The combination of complexity and the nagging issues that have dogged software-centric product development and maintenance suggest that real innovation will only come through systems thinking.

The Waters Foundation, a group dedicated to applying systems thinking to education, suggests a set of “Habits of a Systems Thinker.” The habits¬†are:

  • Seeking to understand the big picture
  • Observing how elements within systems change over time, generating patterns and trends
  • Recognizing that a system‚Äôs structure generates its behavior
  • Identifying the circular nature of complex cause and effect relationships
  • Changing perspectives to increase understanding
  • Surfacing and tests assumptions
  • Considering an issue fully and resists the urge to come to a quick conclusion
  • Considering how mental models affect current reality and the future
  • Using understanding of system structure to identify possible leverage action
  • Considering both short and long-term consequences of actions
  • Finding where unintended consequences emerge
  • Recognizing the impact of time delays when exploring cause and effect relationships
  • Checking results and changes actions if needed: ‚Äúsuccessive approximation‚ÄĚ

These habits illustrate that to really create change you need to take the overall process into account and test all of our assumptions before you can know that your change is effective.

An example presented at¬†MIT‚Äôs System Design and Management (SDM) program on Oct. 22 and 23 exposed the need to address complexity through holistic solutions. A hospital scenario was described in which alarm fatigue has occurred, leading to negative patient outcomes.¬†Alarm fatigue occurs when health professionals are overwhelmed by monitoring medical devices that provide data and alerts.¬† The devices don‚Äôt interoperate, therefore all of the data and alerts just create noise, which can hide real problems.¬† Any IT manager that has reviewed multiple monthly project status reports and updates can appreciate how a specific problem signal could be missed and what the consequences might be. ¬†Systems thinking applied through the filter of the ‚ÄúHabits of a Systems Thinker‚ÄĚ is tailor-made to help us conceptualize, understand and then address complex problems; to find solutions for problems that seem elusive or that reoccur in an organization.


Categories: Process Management

SPaMCAST 415 - Risk Tolerance in Agile, Kotter Change Model, Innovation Bandwagon, Requirements Part 3

Software Process and Measurement Cast - Mon, 10/17/2016 - 01:32

The Software Process and Measurement Cast features four columns.  We begin with our essay on recognizing risk and risk tolerance.  Any discussion of risk begins with acknowledging that risk exists and then recognizing specific risks.  Once we know risks exist we need to determine which risks we care about. Risk tolerance affects how everyone in an organization behaves.

Kim Pries the Software Sensei discusses change models, focusing on the Kotter model of change.  Kim discusses how change models can be used for hardware, software, processes and procedures.  

Gene Hughson brings his wonderful Form Follows Function Blog the podcast.  In this installment, Gene and I discuss All Aboard the Innovation Band Wagon. We talked a lot about how to define innovation AND why innovation and change is powerful.

Jon Quigley anchors the cast with the third installment in a three-part arc on requirements in his ¬†‚ÄúThe Alpha-Omega of Product Development‚ÄĚ column. This week Jon discusses managing requirements.

Re-Read Saturday News

We continue the read/re-read of The Five Dysfunctions of a Team by Patrick Lencioni (published by Jossey-Bass).  We seem to be moving from cliffhanger to cliffhanger over the past few weeks, and we shall do so again today. Lencioni uses crises to illustrate common problems that make teams into dysfunctional collections of individuals. This week we tackle the sections from Entering the Danger to Rebound.

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

Next SPaMCAST

The Software Process and Measurement Cast 416 will feature our interview with Kirk Botula.  Kirk is the CEO of the CMMI Institute.  Kirk and I talked about organizational capability and why capability is crucial for organizational health and agility!

Shameless Ad for my book!

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

Categories: Process Management

SPaMCAST 415 ‚Äď Risk Tolerance in Agile, Kotter Change Model, Innovation Bandwagon, Requirements Part 3

 

SPaMCAST Logo

http://www.spamcast.net

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

The Software Process and Measurement Cast features four columns.  We begin with our essay on recognizing risk and risk tolerance.  Any discussion of risk begins with acknowledging that risk exists and then recognizing specific risks.  Once we know risks exist we need to determine which risks we care about. Risk tolerance affects how everyone in an organization behaves.

Kim Pries the Software Sensei discussers change models, focusing on the Kotter model of change.  Kim discusses how change models can be used for hardware, software, processes and procedures.  

Gene Hughson brings his wonderful Form Follows Function Blog the podcast.  In this installment, Gene and I discuss All Aboard the Innovation Band Wagon. We talked a lot about how to define innovation AND why innovation and change is powerful.

Jon Quigley anchors the cast with the third installment in a three-part arc on requirements in his ¬†‚ÄúThe Alpha-Omega of Product Development‚ÄĚ column. This week Jon discusses managing requirements.

Re-Read Saturday News

We continue the read/re-read of The Five Dysfunctions of a Team by Patrick Lencioni (published by Jossey-Bass).  We seem to be moving from cliffhanger to cliffhanger over the past few weeks, and we shall do so again today. Lencioni uses crises to illustrate common problems that make teams into dysfunctional collections of individuals. This week we tackle the the sections from Entering the Danger to Rebound.

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

Next SPaMCAST

The Software Process and Measurement Cast 416 will feature our interview with Kirk Botula.  Kirk is the CEO of the CMMI Institute.  Kirk and I talked about organizational capability and why capability is crucial for organizational health and agility!

Shameless Ad for my book!

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


Categories: Process Management

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

The Five Dysfunctions of a Team Cover

The “Book” during unboxing!

Today we continue our re-read of the business novel, The Five Dysfunctions of a Team by Patrick Lencioni (Jossey-Bass, Copyright 2002, 33rd printing). If you do not have a copy of the book, please buy a copy from the link above and read along. We seem to be moving from cliffhanger to cliffhanger over the past few weeks and we shall do so again today. The crisis Lencioni illustrates are common problems that make teams into dysfunctional collections of individuals.

Entering the Danger

When we ended our re-read in Week 3, Martin had checked out of the meeting and was absorbed by this laptop. ¬†In response to Martin‚Äôs breach of etiquette, Kathryn states her simple rules for meetings. ¬†The rules are to be present and to participate (I typically add ‘be prepared’ to this simple set of rules). In the ensuing discussion, Mikey states that having a laptop open and on during a meeting is part of the high-tech culture. ¬†Kathryn counters the objection by stating that this is more of a behavioral issue than a technology issue. I frankly have been in meetings where someone is typing away on a¬†phone or laptop, which leads them to fail to pay attention and ask the same question as someone else multiple times even in a short meeting. Having your laptop open sends a message that you are disengaged. In answer to Kathryn‚Äôs challenge to his open laptop, Martin acquiesces and closes the laptop.

Getting Naked

After defusing the laptop incident, Kathryn and the team participates in an exercise called ‚Äúpersonal histories‚ÄĚ, where you tell people about yourself using five questions which are answered one at a time as you go around the room. The goal of the exercise is to begin to build bridges and trust between the Staff. ¬†Sharing, in this case, helps the team to Staff to seem tighter, at least when talking about something less dangerous than work. ¬†Many coaches use these types of tools for team building without recognizing that the gains made while tackling safe topics can erode when teams encounter stressful topics or scenarios.

Going deeper

In order to build on the progress made using the simple personal history technique, the team completes and discusses one of the myriad personality tests (for example, the Myers РBriggs test) as a discussion tool. Kathryn’s goal is to continue to expose each person’s personality to the group so they can build trust. After a discussion, Kathryn gives the group a break to decompress before meeting for cocktails and dinner.

As the team has cocktails and discusses the day, they interact through conversation that includes light banter and ribbing that is often seen among people that are comfortable together. While the majority of the group is participating, Mikey is standoffish. When Nick (and others) suggest the personality test description is accurate, Mikey reacts with derision (eye rolling).  When called on her reaction Mikey goes into a negative tirade about the process that they were going through.  I will admit, that I have gone into the same tirade when these types of tests are used for hiring and firing decisions rather than discussion tools. The discussion and attendant tirade caused Mikey to become even less participative.  Failing to interact during drinks and dinner screamed that that Mikey does not trust her teammates. Note: we have shifted from Martin being the primary purveyor of problems to Mikey.

Poolside

The dinner meeting ends at 10 with most of the Staff heading back to their rooms. ¬†As they drift back to their rooms Kathryn talked¬†with Mikey. ¬†Mikey‚Äôs reaction was a further withdrawal. ¬†Telling Kathryn that she would not let people make fun of her at home so she sure as heck wasn’t going to let people make fun of her work (reacting to the intermural ribbing before dinner). The reaction is a powerful sign that Mikey is keeping the rest of the team at arms’-length. Mikey went on to say that she would not talk about her issues with the process the next day. Mikey‚Äôs reaction suggested that she was checking out of the process and she felt that she was outside and more important than the whole of the team.

Rebound

Kathryn used the beginning of the second day to review and discuss the progress the Staff had made the day before. ¬†Mikey’s participation was limited, and when she talked the energy and the pace of the actively seemed to slow down. ¬†I think we can all recall a scenario in which the tone or phrasing of comment generates a negative environment. ¬†Sarcasm is often used to state a positive in a negative manner. ¬†An hour before lunch, Kathryn what the book describes as, ‚Äúthe most important exercise of the day which would be looked back on as the moment of truth for Mikey and the rest of the team.‚ÄĚ ‚Äď We end on a cliffhanger to hold you until next week.¬†

We end on another cliffhanger keep you on the edge of your seat until next week!

Three quick take-ups:

  1. In meetings be present, participate, and be prepared!
  2. Everyone on a team needs to trust each other.
  3. No one person on a team is more important than the team.

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

Week 1 ‚Äď Introduction through Observations

Week 2 ‚Äď The Staff through the End Run

Week 3 ‚Äď Drawing the Line though Pushing Back


Categories: Process Management

ISO/IEC 27001:2013 and Scrum 5 Ways to Make it Less Painful

Xebia Blog - Sat, 10/15/2016 - 12:48
At some point, you get a nose for things that don’t feel right. Things that sound reasonable when explained, yet you get that gnawing feeling it sort of goes against nature. Working with Scrum and compliance to ISO is one of those things. Here are 5 ways to merge a rigid security standard, without violating

Systems and Systems Thinking

 

Credit card billing systems are a useful way to explore systems thinking.

Credit card billing systems are a useful way to explore systems thinking.

The world made up of interlocking systems. At more finite level, such as a company or product, understanding systems is crucial for being effective and efficient.  For example, have you ever observed a team spend time researching, prototyping, piloting and then implementing a change to improve a product’s delivery rate, only to find that the process change yields little to no big picture impact? The second or third time you make this observation it drives the point home that optimizing steps within a system doesn’t always translate into better overall performance.  We need to think of the system as a whole.  Systems thinking pushes us to take a more holistic path.

A¬†system is a group of interacting, interrelated, and interdependent components that form a complex and unified whole.¬† Russell Ackoff, the management guru, defined a system as ‚Äúan entity which is composed of at least two elements and a relation that holds between each of its elements and at least one other element in the set. Each of a system‚Äôs elements is connected to every other element, directly or indirectly. Furthermore, no subset of elements is unrelated to any other subset.” ¬†A critical core to these definitions is that a system is a number of related components that interact.¬† I add that the core of most (if not all) systems operate within a larger systems ecology that they interact with and which provide feedback and guidance.

There are several defining characteristics of a system.  They include:

  1. Every system has a purpose and operates within a larger system.
     Example: The purpose of a credit card billing system is to account for charges and to send cardholders a bill on a monthly basis. However, if there is no mechanism for using the card, authorizing charges or recording transactions, the system has no value.
  2. All of a system’s parts must be present for the system to carry out its purpose. In other words, if you removed any one of the components, the system would fail to meet its purpose.
    Example: A billing system without the ability to print or export the bill is not done.
  3. A system’s components have a specific order.
    Example: In the credit card billing system, charges need to be authorized and then posted before they can be included in a bill.
  4. Systems interact with their environment and generate feedback.
    Example:  A credit card billing system will interact with interact with the calendar, interest rates and many operational components to operate effectively.
  5. Feedback provides a mechanism to make adjustments.
    Example:  The number of customers in a specific billing cycle is typically adjusted based on load.  If everyone cycled on the last day of the month, processing would never complete on that day.  Load balancing is a feedback mechanism.

Systems thinking is an approach to problem solving that emphasizes the whole process, including the environment the system operates within. It leverages the five characteristics of systems as a framework for analysis and action.  Feedback from both inside and outside the system are control mechanisms that ensure the system performs as expected.  The overall impact of a change to an individual component will be affected by the performance of all of the components in the system.  For example, completing the framing of the house will only get the finished house done sooner if the contractors performing the following steps move their schedules up. In this example, feedback from all of the other contractor’s schedules is needed to determine whether completing the framing more quickly will have value. Would it make sense to pay carpenters overtime to complete the framing earlier if the houses completion date was not affected? Systems thinking is the understanding of how things fit together, are influenced, and generate influence.  It is a framework for understanding the big picture.


Categories: Process Management

Quote of the Month October 2016

From the Editor of Methods & Tools - Wed, 10/12/2016 - 12:00
If you blindly accept what clients say they want and proceed with a project on that basis, both you and the clients may be in for a rude awakening. You will have built something the clients cannot use. Often in the process of building a solution, the clients learn what they need is not the […]