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/6&page=5' 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!

Project 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.

Stuck in the Middle with Your Agile Transformation? Part 1

Here’s something I see in many organizations: Management wants to “control and manage” the projects/efforts/work (whatever they call it) in the same way they did before the organization started agile. They want Gantt charts. They want commitments. They want assurances that the work will proceed in the same way they thought of it before the project started.

In the meantime, the project teams revel in the adaptability of being able to re-rank the backlog and show value. They progress on the work the Product Owner wants, in the order the PO wants it.

If you are a manager, project manager, or a change artist in your organization, I bet you are dismayed. Management is not nurturing an environment in which agile can thrive—and more important—the managers don’t receive the value of agile.

You are stuck in the middle.

Agile (and lean) help us to deliver constant streams of value. Once we deliver, we can change what we work on next. If you have small stories, you can deliver and change every day. I don’t recommend changing every day—I prefer a slightly longer perspective. But you could. I wrote about this in a Pragmatic Manager last year, called¬†Commitments or Resilience.

You have a problem. What is it, and how can you solve it? You might need some data:

  • What problems does your management have?
  • How will agile help solve those problems?
  • What does agile success look like for your management?

These questions are part of getting ready to coach and influence your management. When you ask these questions, you learn what is in it for the managers (WIIFM in influence terms), and what you might need to measure to help everyone understand how agile can help. If you feel stuck in the middle, join Gil Broza and me when we address these issues in the Influential Agile Leader in Boston and London this year.

Sometimes, it’s not just management who is a little stuck in the agile transition. Sometimes, it’s the team(s), too. I’ll address the team concerns in Part 2.

Categories: Project Management

Stuck in the Middle with Your Agile Transformation? Part 2

In Stuck in the Middle, Part 1, I discussed possible management problems with agile. Those aren’t the only stuck problems I see. Sometimes, I see team problems.

What if the teams are “almost agile”—they still have too many experts, their stories are too big, they don’t always deliver value on a regular basis? You know they could see the benefits of agile if they retrospected, or changed the way they work. Maybe they don’t quite know what to do.

I also tackled some of these concerns with blog posts:

Understanding the problems—and helping the team understand the problems—is your first step in¬†helping to solve the problems.

I wrote some newsletters that might help:

I admit, it would be nice if we could tell people what to do. I have found that telling doesn’t work so well when we want people to be self-managing. (!!) What can you do?

  • Build your coaching skills so you can coach across the organization.
  • Build your influence skills so you can influence anywhere.
  • Understand the dynamics that prevent the teams from succeeding as well as they could.

We do all of these at the Influential Agile Leader. I invite you to join us this year, in Boston or London.

In Part 3, I’ll discuss the system of agile that makes being stuck in the middle uncomfortable.

Categories: Project Management

Stuck in the Middle with Your Agile Transformation? Part 3

In part 1, I addressed some management challenges with an agile transition. In part 2, I addressed some team issues.

In this part, I’ll discuss why agile is a culture change and ways to consider a system change to agile.

general-agile-picture-copyright-300x189

Agile looks something like this image.

The responsible person (often called a product owner) collects ideas and creates a ranked backlog for a cross-functional team. The team works on the backlog, releasing small chunks of value. At some point, the team demos to the product owner, retrospects and gets an updated backlog.

The system depends on these ideas:

  • The team finishes small chunks of valuable work so the team and the product owner can get feedback about the story size and work to date. This requires the team finish their work. (You know, the discussions about done.)
  • The team retrospects often enough to understand and fine-tune the team’s process.
  • The team, including the product owner, retrospect enough to understand if the stories are small enough for the team to finish stories, and to change what the team works on when. Retrospectives include the product and the process.

This is a cultural change in these dimensions:

  • From a culture of commitments through documents to a culture of commitments through working product
  • From a culture of individual work (resource efficiency) to a culture of teamwork (flow efficiency)
  • From a culture of management control (of the team) to team control of itself (self-management)

Culture change does not occur overnight.  Change is hard work.

If you are one of the people nurturing your agile change, I bet you feel stuck in the middle between other managers, the manager(s) and the team(s). I invite you to join us at the Influential Agile Leader (Boston Apr 6-7, and London May 4-5) this year.

Categories: Project Management

User Stories are Not Requirements and Other Things They Are Not

Herding Cats - Glen Alleman - Tue, 02/16/2016 - 16:00

Let's start with the simple idea that Requirements are required items from the project. Capabilities that the project must produce in order for it to earn back its cost to produce. User Stories are a narrative of what the User would like the resulting software to do in some way. It's a story of how a problem or a need could be solved. It's not a requirement that it solve it in some specific manner. Requirements state the specific outcome.

  • We need¬†rendezvous¬†and dock with the International Space Station, with 4 Pacs on board, stay for 6 months, return to the landing zone safely. Is a Capability.
  • We must use the Low Impact Docking System to connect the Crew Exploration Vehicle with the International Space Station¬†at Node Two using the Pressurized¬†Mating Adapter.

In the software development world...

  • We must provide a computer system that is capable of enrolling 750,000 clients in this years health system starting in March and lasting no longer than 45 days - is a Capability.
  • All enrollment submissions must use a system that provides remote verification of location, SSN, IRS, and DL data interfaced with Local, State, and Federal system prior to review of benefits defined in XML format in accordance with CMS standards - is a requirement.

Capabilities describe how the produced system will enable the value to be delivered as planned. Requirements describe how the Capabilities will be delivered. Stories are narrative as to how those Capabilities will be used and provide the raw data as to how the Requirements will emerge.

Now For The Punch Line

Using User Stories to predict project performance is also NOT a role of User Stories. User Stories are vague narratives of a customer's desire. They can change, and likely will change as the project moves forward. They are ersatz models of what the software will do when it is done. The naive notion that ...

You can easily predict the release date of a project by just counting the number of Stories

... can only be the case, If and Only If the User Stories never change in their implementation detail, are near exact representation sof what the user wants in terms of Capabilities and the Requirements needed to provide those Capabilities, and most importantly the future is nearly exactly like the past - so the performance that happened in the past will also happen in the future.

As well there can be no emergent risk, no change in effectiveness of labor, nothing will change. This is not only naive, it ignores - some would say willfully ignores - the fact that all project work is uncertain. In the presence of this uncertainty measuring the probability of meeting the planned need date for the planned cost (remember ROI is a core business assessment of the project's performance), and the probability that the needed Capabilities will in fact be delivered as needed cannot be  assessed using a measure that is itself vague, emerging, variable in undefined ways, and not actually representative of Physical Percent Complete for the work being performed.

Related articles Some More Background on Probability, Needed for Estimating Populist versus Technical View of Problems How to Deal With Complexity In Software Projects? Business Rhythm Drives Process How Think Like a Rocket Scientist - Irreducible Complexity Systems Engineering in the Enterprise IT Domain Three Increasingly Mature Views of Estimate Making in IT Projects Capabilities Based Planning First Then Requirements
Categories: Project Management

User Stories are Not Requirements and Other Things They Are Not

Herding Cats - Glen Alleman - Tue, 02/16/2016 - 16:00

Let's start with the simple idea that Requirements are required items from the project. Capabilities that the project must produce in order for it to earn back its cost to produce. User Stories are a narrative of what the User would like the resulting software to do in some way. It's a story of how a problem or a need could be solved. It's not a requirement that it solve it in some specific manner. Requirements state the specific outcome.

  • We need¬†rendezvous¬†and dock with the International Space Station, with 4 Pacs on board, stay for 6 months, return to the landing zone safely. Is a Capability.
  • We must use the Low Impact Docking System to connect the Crew Exploration Vehicle with the International Space Station¬†at Node Two using the Pressurized¬†Mating Adapter.

In the software development world...

  • We must provide a computer system that is capable of enrolling 750,000 clients in this years health system starting in March and lasting no longer than 45 days - is a Capability.
  • All enrollment submissions must use a system that provides remote verification of location, SSN, IRS, and DL data interfaced with Local, State, and Federal system prior to review of benefits defined in XML format in accordance with CMS standards - is a requirement.

Capabilities describe how the produced system will enable the value to be delivered as planned. Requirements describe how the Capabilities will be delivered. Stories are narrative as to how those Capabilities will be used and provide the raw data as to how the Requirements will emerge.

Now For The Punch Line

Using User Stories to predict project performance is also NOT a role of User Stories. User Stories are vague narratives of a customer's desire. They can change, and likely will change as the project moves forward. They are ersatz models of what the software will do when it is done. The naive notion that ...

You can easily predict the release date of a project by just counting the number of Stories

... can only be the case, If and Only If the User Stories never change in their implementation detail, are near exact representation sof what the user wants in terms of Capabilities and the Requirements needed to provide those Capabilities, and most importantly the future is nearly exactly like the past - so the performance that happened in the past will also happen in the future.

As well there can be no emergent risk, no change in effectiveness of labor, nothing will change. This is not only naive, it ignores - some would say willfully ignores - the fact that all project work is uncertain. In the presence of this uncertainty measuring the probability of meeting the planned need date for the planned cost (remember ROI is a core business assessment of the project's performance), and the probability that the needed Capabilities will in fact be delivered as needed cannot be  assessed using a measure that is itself vague, emerging, variable in undefined ways, and not actually representative of Physical Percent Complete for the work being performed.

Related articles Some More Background on Probability, Needed for Estimating Populist versus Technical View of Problems How to Deal With Complexity In Software Projects? Business Rhythm Drives Process How Think Like a Rocket Scientist - Irreducible Complexity Systems Engineering in the Enterprise IT Domain Three Increasingly Mature Views of Estimate Making in IT Projects Capabilities Based Planning First Then Requirements
Categories: Project Management

Quote of the Month February 2016

From the Editor of Methods & Tools - Mon, 02/15/2016 - 10:47
Ask somebody in the building industry to visually communicate the architecture of a building and you‚Äôll likely be presented with site plans, floor plans, elevation views, cross-section views and detail drawings. In contrast, ask a software developer to communicate the software architecture of a software system using diagrams and you‚Äôll likely get a confused mess […]

Drip Funding, Slicing, Decomposing Large Projects Into Small Projects?

Herding Cats - Glen Alleman - Wed, 02/10/2016 - 18:54

Drip Funding, Slicing, Decomposing Large Projects Into Small Projects are popular platitudes of the agile community and have been picked up by the #NoEstimates community as the response to questions about funding work, business processes, managerial finance and making decisions in the presence of uncertainty.

A domain is always needed before any suggestion for anything can be assessed to be applicable and useful beyond personal anecdotes.

Let's look at an actual program for a Health Insurance Enterprise system provider network system. The diagram below shows what capabilities neeed to be produced in what order for the system to be of any use to the business.

This by the way is a critical issue in the agile development paradigm. The customer may prioritize what Features come first. But there is a business architecture in place for any enterprise system. The order of the work is not arbitrary. Partially completed software components are of little use. Drip funding and Drip delivery may be fine for simple applications. But a System of Systems no longer has an arbitrary order of the work. It's a working system and the capabilities need to appear in the right order for any value to be produce. This order of delivery is engineered not emergent.

In the example below, the systems starts with a legacy suite of applications. The final system is an ERP style claims processing system, provider network integration, and a Data Mart for the information associated with processing claims from the provider. This type of development, integration, and evolutionary deployment is common when there is a mix of legacy and new components. Even in the new components - say green field deployment of SAP. But rarely today is there an Green Field deployment in any non-trivial environment.

The way this diagram reads is things in Boxes are system capabilities, complete with Definition of Done - not in the simple Agile DoD. But with Measures of Effectiveness, Measures of Performance, Technical Performance Measures, and Key Performance Parameters. All defined upfront.  These are not requirements, they are what Done Looks Like in units of measure meaningful to the decision makers.  

The connections between the boxes - moving left to right - are the sequences of the needed capabilities to have them be useful to the business. For example having a Pilot alone isn't much use. Having the Pilot and having real data for that Pilot to work on for a Demonstration of the Conversation process and Member Reconciliation is useful. This notion is how to read the chart.

Screen Shot 2015-12-28 at 6.36.37 PM

By the Way this chart is just a different version of an Integrated Master Plan. This is not by accident. Several of the senior managers on this program, along with our team, work in the Space and Defense business as well, where Software Intensive System of Systems are the norm.  The Integrated Master Plan / Integrated Master Schedule programmatic architecture looks like this. Where tangible business benefits are at the Event Level, the Significant Accomplishments needed to produce those benefits are next, and the Accomplishment Criteria are the exit criteria for the Work Packages (Features in Scrum) needed to produce the working software that can be put to use by the business.

Screen Shot 2015-12-28 at 6.47.40 PM

The connectivity between the IMP elements (Events, Accomplishments, and Criteria) and the Work Packages in the IMS looks like this:

Screen Shot 2015-12-28 at 6.49.14 PM

All This is a Set Up for the Questions In the Title

If we have the typical enterprise legacy integration with new enterprise application - the vast majority of work in IT,  ...

  • Can Drip Funding be used to deploy this enterprise system?
  • Can the work be sliced into smaller incremental deliveries?
  • Can this big project be broken down into a bunch of small projects?

Drip Funding

Drip Funding is claimed to be a way of developing software without having to estimate how much it will cost in the end. Of course this ignores the basic managerial finance principles of any enterprise effort. That principle says, someone, somewhere in the organization who is accountable for spending money has a fiduciary need to how much will be spent, when that expenditure will turn into productive use for accounting purposes of FASB 86, and what is the cash flow for expense curve look like against the bookable value to the firm. 

So Drip Funding also needs Drip Benefits, in the terms of revenue if this is an external project or bookable benefits if this is an internal project. Expense and Capitalization opportunities are also needed for the integrity of the balance sheet every month. How much did we spend, how much will we spend, when will we start to see the rewards from that spend so we can start to balance the books on that expenditure?

Looking back to the Capabilities flow picture, we can certainly incrementally fund work to produce a working capability. But dolling out money in Drips may or may not get us there. How big do the Drips need to be? When do they need to arrive?  There is a difference between allocated funds and committed funds. There may be budget for the work, but authorizing the spend for the work is different. 

While Drip Funding is a popular term in Agile, those accountable for the firms spend - cost accounting and the CFO - need to weigh in on the balance sheet aspects of providing incremental funds with some expectation of when they will get their money back. This is standard Managerial Finance and also the basis of decision making in the paradigm of Microeconomics. If I have a fixed amount to spend, what are the choices that can be made that will produce a tangible beneficial outcome in exchange for that spend? The first number is fixed (usually), the other numbers (benefits and when) are uncertain and require estimates to be made to close the loop of the decision making process.

 

Related articles Build a Risk Adjusted Project Plan in 6 Steps How Think Like a Rocket Scientist - Irreducible Complexity Impact Mapping and Integrated Master Planning 5 Questions That Need Answers for Project Success Herding Cats: What does done look like? How to Deal With Complexity In Software Projects?
Categories: Project Management

The Economics of Sofware Quality

Herding Cats - Glen Alleman - Wed, 02/10/2016 - 02:05

Economics of SWTo predict the future of a software project with acceptable accuracy and precision, it is necessary to measure past project and keep track of current and ongoing projects. Estimation and  measurement are closely aligned, and good historical data is of great value in estimating future outcomes of future software projects. - Opening of Chapter 2 of the book to the left.

Software Development, using other peoples money in the presence of uncertainty is a microeconomics paradigm. What choices are needed to assure project success, confirm that the funding invested produces the planned return on that spend? What choices are best for the current understanding of the uncertainties faced by the project. Both reducible and irreducible uncertainties?

To suggest decisions can be made without estimating the outcome of those choices it to willfully ignore the foundation principles of microeconomics and managerial finance of software development projects.

Those conjecturing those decisions can be made without making estimates, are participants in this willful ignorance.

Categories: Project Management

The Economics of Sofware Quality

Herding Cats - Glen Alleman - Wed, 02/10/2016 - 02:05

Economics of SWTo predict the future of a software project with acceptable accuracy and precision, it is necessary to measure past project and keep track of current and ongoing projects. Estimation and  measurement are closely aligned, and good historical data is of great value in estimating future outcomes of future software projects. - Opening of Chapter 2 of the book to the left.

Software Development, using other peoples money in the presence of uncertainty is a microeconomics paradigm. What choices are needed to assure project success, confirm that the funding invested produces the planned return on that spend? What choices are best for the current understanding of the uncertainties faced by the project. Both reducible and irreducible uncertainties?

To suggest decisions can be made without estimating the outcome of those choices it to willfully ignore the foundation principles of microeconomics and managerial finance of software development projects.

Those conjecturing those decisions can be made without making estimates, are participants in this willful ignorance.

Categories: Project Management

Should Scrum Teams Include a Stretch Goal In Their Sprints?

Mike Cohn's Blog - Tue, 02/09/2016 - 16:00

There are, of course, a variety of ways to go about planning a sprint. I’ve written previously about velocity-driven sprint planning and commitment-driven sprint planning and my preference. But regardless of which approach a team takes to sprint planning, there is also the question of how full to fill the sprint.

Some teams prefer to leave plenty of excess capacity in each sprint, perhaps so there is time for emergent needs or experimentation. Other teams prefer to fill the sprint to the best of their ability to forecast their capacity.

Still other teams like to take on a “stretch goal” each sprint, which is kind of a product backlog item that is not quite in the sprint, but is one the team hopes to complete if the sprint goes well.

In this post, I’d like to share my thoughts on bringing a stretch goal into a sprint.

This is one of those things that needs to be left entirely up to the team. It should not be up to the ScrumMaster or the product owner, but up to the team. Some teams do extremely well with a stretch goal. Other teams do not.

It really depends on how the team views the stretch goal.

For example, I feel stretch goals are like a crushing weight. I feel like I need to complete them. When I set a goal, I almost always achieve it. I have a hard time distinguishing between what I call a “normal goal” and stretch goal. I don’t think this is good, but it’s who I am. But, I’m not the only one who does this.

If a team included me and perhaps a couple of others like me, we would probably not do well with a stretch goal. The stretch goal would likely be in our minds and possibly even affect our ability to finish all of the main work of the sprint.

Other people--those unlike me--have what I’ll call a more mature attitude toward stretch goals. They can look at it as it’s intended. They can think, “OK, great if we get to it but no big deal if not.” Teams comprising mostly people like that will probably do quite well with a stretch goal.

So: Should your team have a stretch goal in their sprints?

This really has to be up to the team. Unless I’m on the team. Then the answer is no.

Does Your Team Use Stretch Goals?

What do you do? Does your team use stretch goals? Does it help? Please share your thoughts in the comments below.

Managing Programmers

From the Editor of Methods & Tools - Tue, 02/09/2016 - 15:24
Programmers are not like the other kids. They cannot and should not be managed like normal people if your intent is to produce high quality software. The things you would do to make the process go faster will actually make things go slower. This session gives you insight on the care and feeding of programmers, […]

Thinking About Servant Leadership and Agile Project Management

For many people, agile means an end to all project management. I disagree. I find value in servant leadership in project management.

I explain how you can think about servant leadership and agile project management in my projectmanagement.com column this month: Servant Leadership: The Agile Way.

If you are looking to increase your servant leadership and help your project team (or program), check out the Influential Agile Leader.

Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Mon, 02/08/2016 - 21:17

They constructed ladders to reach to the top of the enemy's wall, and they did this by calculating the height of the wall from the number of layers of bricks at a point which was facing in their direction and had not been plastered. The layers were counted by a lot of people at the same time, and though some were likely to get the figure wrong  the majorly would got it right .... Thus, guessing what the thickness of a single brick was, they calculated how long their ladder would have to be. - Thucydides, The Peloponnesian War

So when you hear, we don't need to estimate to know when we're done, that willfully ignores all the naturally occurring variances and the event based variances in all our project work. The Greeks knew this, we need to heed their advice.

Categories: Project Management

Successful Software Development Project Failures

From the Editor of Methods & Tools - Mon, 02/01/2016 - 15:10
Software development projects have always been challenging. The most referenced source for metrics about project success is the Standish Group yearly CHAOS report. According to this source, around 30% of software development project were considered as a “failure” in the recent years. The failure rate of larger projects is a little bit higher than the […]

Thu, 01/01/1970 - 01:00