Essential Parts of Software Development

April 2, 2018 — Posted by Al Shalloway

I wrote a series of posts on linkedin and duplicated them here:

  1. The lessons of complex systems
  2. The dilemma of change
  3. How to provide a system for adopting Lean-Agile in an organization
  4. The missing piece of Agile: Agile Product Management
  5. Why you need a test-first mindset
  6. How to improve your Scrum endeavors
  7. How to improve your technology
  8. The Importance of Lean-Agile
  9. The role of management in Lean-Agile

Since they are posts, they will all be short. I will put both a place to find resources in the first comment as well as an invitation to help. As many of you know, I publish a lot. The motivation for me is that I see people are unaware of approaches that they can use to extend popular methods or that can even be used on their own. My company offers consulting, training and coaching on pretty much everything I have ever written about (I write from experience). If my writings resonate with you and you are about to undergo some initiatives, please send me a note.

The lessons of complex systems

Much of the discussion around complexity has the tone that predictability is not possible. But that’s not totally true. Go into all but the most successful companies & we can predict we will find them working on too many things, having too many interruptions, changing requirements, poor collaboration, frustration, and more. Seasoned veterans of organizational change can typically ask a few questions & predict many things that’ll be present. This is not precognition. It is a reflection that the behavior in an organization is a reflection of the system they have.

The valuable lessons of complexity are:

  1. Companies are not just complex, they are systems. We must take a systems-thinking approach & consider the organization as a whole-attending to the relationships between its components, not just the pieces
  2. Quick feedback is required to steer change
  3. Frameworks introduced to systems become part of the system & may not fit the system they are trying to change
  4. Focusing on one aspect of a company, even when success is achieved, may have unintentional side effects on other parts of the company
  5. While we can take insights from successful companies, we cannot copy them doing because their culture is different from ours

The dilemma of change

I hear that people resist change. I suggest not always & when they do it is often the imposition of change. If management provides an improved environment for people, one that enables self-organization, creates a greater understanding of why people are being asked to do their work, results in fewer interruptions, makes it easier for them to work with their colleagues, provides a bigger picture so they can make better decisions & get a sense of real accomplishment to to their organization, then people will often embrace the change.

But this is complicated by:

  1. Most people need a well-defined starting point for change
  2. No one-size fits all
  3. Who decides on the change is motivated by different factors than the people who are affected by it

The net result is often an attempt to create change with predefined frameworks. But as mentioned in my prior post, these now become part of the system & they may not have been designed for the company.

What’s a better way? You don’t need to swear off predefined methods. They have a lot of good in them or they wouldn’t be popular. But they should not be considered as a take all or leave it approach. Understand how you company will react to their introduction and adjust accordingly.

How to provide a system for adopting Lean-Agile in an organization

A lot of organizations are moving to Lean and/or Agile methods using canned solutions to provide the needed specific and well defined starting point. This set up the dilemma, however, that no one size fits all. In addition, needs change as organizations learn.

What is required is an operating model that provides a well-defined start that can be adjusted as the organization improves. The process to do this is as follows:

  1. See where you are
  2. understand the challenges you are having
  3. Learn a few key principles and practices that will help you overcome these challenges
  4. Decide how to begin using a set of patterns that solve these challenges
  5. Start by adopting these patterns and adjust as needed

To support these steps we have found it necessary to have everyone agree to:

  • Focus on the realization of value
  • Collaborate with each
  • Ensure that all work is visible.
  • Sustain or increase predictability.
  • Keep the work throughout the value stream within capacity.
  • Continuously improve

We have created both FLEX (FLow for Enterprise Transformation) to help select the needed patterns and the Guardrails system to define the agreements people in your organization must follow.

The missing piece of Agile: Agile Product Management 

APM concerns itself w/defining the value to be manifested by the business that aligns with its strategic goals. It requires:

  1. Identifying, sizing &sequencing the work to be done to facilitate alignment across the enterprise. This includes the use of MVPs &their counterpart in established organizations MBIs
  2. Using the relationship between business offerings &capabilities to improve the organization's methods &understanding why not doing this hurts alignment
  3. Creating an effective ecosystem for this & its required roles
  4. Using Behavioral Driven Development (BDD) or ATDD to create clarity on requirements

The first two steps are the most critical & require more than prod mgrs &owners. Without attending to how a new offering effects existing capabilities, items required for delivery are often missed. Furthermore, WSJF cannot be done effectively on epics as not all of a epic is needed. Nor can one do it effectively on features as many features, in and of themselves, do not provide value to the customer

Agile has been evolved from development both back to ops & up to business, but it has not reached budgeting as yet, &until it does, many issues will not be successfully resolved.

Why we need a Test-First mindset

Test-first is often associated with eXtreme Programming’s Test-Driven Development (TDD). TDD is about “how will I know I’ve done what’s requested” & how can I know it’s still being done after other changes are made. One reason this works well in development is it follows the 1st mantra of design patterns–“design to the behavior of the system”

But test-first goes well beyond the team. We must also know that what’s being requested is what should be being requested.

One major challenge with requirements is that we don’t know what we don’t know. Questions that need to be asked aren’t. This is exacerbated by the fact that languages are ambiguous. For example, there are signs on doors that say “this door to remain locked at all times.” How do you get through that door if it’s always locked. Clearly, the door doesn’t meet its own requirement. When people have different backgrounds (eg coders & POs) there is often a difference between words and meaning.

Consider that answering the question “how will I know I’ve done what’s requested” can clear up these misunderstandings. This doesn’t take any extra time as the question has to be considered at some point. The desired answer to this questions is the “test” you need to specify first

 How to Improve your Scrum endeavors

The Scrum Guide says “Scrum’s roles, events, artifacts, &rules are immutable”

Changes to Scrum include:

  1. Just dropping practices
  2. Changes made that improve Scrum but don’t follow the guide
  3. Add practices

The first two are called “Scrum-but” &are often derided. But there are times certain Scrum practices are either not achievable or desirable. Even when you do Scrum by the book (or especially) we find most teams new to Scrum have the following challenges:

  1.  Estimation takes a long time
  2.  Difficulty getting to small (<= 3 days to complete) stories
  3. Too many backlog items get opened too early
  4. Teams get interrupted & management doesn't know the toll on the team
  5. The burndown/up graphs look like hockey sticks
  6. Developers discover they didn't understand the requirement

To do Scrum that fits you & to avoid these common challenges your trainer should

  1. Tailor Scrum to fit software development
  2. Tailor it a little more to fit your own company
  3. Provide a support system for you to refer to
  4. Explain how to replace practices with others that fit you &still meet the objective of the practice you're replace

And get real Scrum Master training. That takes a couple of hrs a week over a few months.

How to improve your technology

While we’ve known what to do when it comes to designing, writing & testing code for almost two decades now, little evidence of that shows up in the code we see. We understand more than we do. There are many reasons for this. The pace at which technology is changing & the widespread adoption of Agile has resulted in an overall lowering of experience & discipline while raising the level of being overworked & franticness. Worse, people overestimate what they think know-especially in the area of object-orientation & patterns (knowing an OO language & a few patterns is far from sufficient).

While training is good when you can afford it (& time is a bigger issue than $s) we learn best in small steps, & by doing actual work. What we need to do is develop practices- activities that take virtually no time but provide value much of the time.

These are particularly useful:

  • Programming by intention
  • Separate Use from construction
  • Define tests up-front
  • Shalloway’s law
  • Encapsulate that

There are other techniques to be sure. But, given the investment in these is practically zero and the return is often high, the ROI is pretty significant.

The importance of Lean-Agile

Lean & Agile must go together. Each provides a part of what’s necessary for effective product/IT dev. Agile’s about the team &'s best personified by Scrum, although it’s not the def of Agile. Scrum was defined for a self-contained team to design & build a product. In that context it is a brilliant framework for creating great teams to build complex products. Unfortunately, w/the ubiquitous adoption of Agile, that is now rarely where it is being used. Many of the challenges we see in Scrum are due to it being a victim of its own success.

There’s more to prod dev than the team. Especially in orgs with more than 3 teams. Lean provides us w/a bigger view. In a nutshell, Lean is about leadership, systems-thinking, process integrity, creating value, just-in-time, quality, visibility, & continuous improvement. Lean provides the bigger, holistic view. It creates the context within which great teams can align while maintaining autonomy. The goal's not to “be Agile” the goal is to create value quickly, predictably, sustainably &w/ high quality. This can only be done w/great teams aligned for a bigger purpose than themselves. This benefits the customer, the business & is the people. Providing purpose is the greatest way to respect people

The role of management in Lean-Agile

Management is a critical role in organizations. It’s become vogue to call it “servant leadership” but that hides it’s true purpose. Management is not just servant leadership, albeit that’s a critical part of it. The manager plays a dual role-helping create an organization that will manifest the vision of its leaders while creating an environment that enables teams to flourish and creates meaning and the ability for individuals to contribute- the highest form of respecting people.

Leadership alone with a top-down view, or teams alone with a bottom up view will not suffice. Middle management, often called the permafrost of Agile, is the key player in this. The purpose of management is to look up to see the vision and roadmap of the organization. Then look down to create (with servant leadership) an environment in which people can work autonomously, but in alignment, to create the vision.

A great resource for this is “Toward Middle-Up-Down Management: Accelerating Information Creation” (’88) by Ikujiro Nonaka, one of the co-writers of “The New New Product Development Game” (’86) which inspired Scrum. The two go together. We need to acknowledge it is no more just about teams than a car is just about its engine.

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban