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!

Feed aggregator

Five Immutable Principles of Project Success Requires Estimating

Herding Cats - Glen Alleman - Sat, 06/10/2017 - 21:02

There are Five Immutable Principles of Project Success.

Screen Shot 2017-06-09 at 9.24.28 AMEach question requires an answer with sufficient confidence to make decisions about spending other people's money, that increases the probability of project success.

All project work is probabilistic (actually statistical and probabilistic), with reducible and irreducible uncertainties that create reducible and irreducible risks to the success of the project.

Let's look at what estimates are needed to answer each of the Five questions:

Principle Estimate Needed To Answer The Question What does DONE look like in units of measure meaningful to the decision makers?

DONE is always in units of business value. That Business Value has variance and that variance needs to be known to assure that the range of Value is tolerable for those paying. 

DONE is a delivered Capability that can be (should be) measured in a unit of Effectiveness and Performance. [1]

A core principle of Managerial Finance is Value cannot be determined without knowing the Cost to achieve that Value. 

So we need to know something about both measures - Cost and Value - to decide that what we think is DONE is affordable, arrives at the needed time to fulfill our business needs, and the cost of this Value can be sustained over the Value's delivery lifecycle.

Without estimates, the units of measure of DONE have no confidence that they will deliver the needed Value or the Cost to achieve that Value is possible before spending all the money and using all the time.

What's our plan to reach DONE as needed for the customer to receive the expected Value from our work?

A Plan is a Strategy for the success of the project. Strategies are hypotheses. Hypotheses require tests to confirm they represent the reality of the situation. 

With these hypotheses, we need to answer the question what's our confidence that the plan we have will actually work?

There is a bigger and better question though ... what confidence DO WE NEED in the plan for the Plan to be credible?

Anyone can construct a Plan. Is it a Credible Plan? Good question. Each requires us to make an estimate of the confidence in the elements of the Plan.

In our Software Intensive System of Systems world, this is called Probability of Program Success (PoPS).

What resources will we need to satisfy the business goals of the customer?

 For the project to be successful, we need resources. People, Facilities, Money, and Time.

How many people, of what skills? What facilities, tools? How much money? How much time?

Each of these needs is probabilistic when it comes to fulfilling the need. What range of variability can we tolerate? This requires making estimates and assessing that impact on the probability of success of the project.

What impediments will we encounter that will reduce the probability of reaching our business goal as needed for the customer to pay back the cost of delivering the needed Value

Risk Management is How Adults Manage Projects - Tim Lister.

All risk management operates in the presence of uncertainty. Making decisions in the presence of uncertainty requires estimating the outcomes of those decisions, the costs associated with those decisions.

You manage projects in the absence of risk management. 

You can't apply risk management without estimating.

No risk management? No adult management.

How are we going to measure progress toward DONE, in some unit meaningful to those paying for our work?

 Physical Percent Complete is the best measure of progress to plan. This is the beauty of Agile Development. Working Software is the Measure of Progress.

But that working software's arrival rate is statistically distributed. The notion of a burndown chart and the projection of progress to show the completion date ignores the statistical nature of software development and the statistical nature of the past performance. 

Many examples from NE show wild varainces in the past performance, but not the impact on the confidence of the complete date or cost. 

To show a confidence range on the completion date from the past performance - the empirical data - we need to estimate the possible ranges of performance in the future from the past performance AND from the possible risks in the future.

Estimates are needed to apply the Five Immutable Principles of Project Success 

[1] System Analysis, Design, and Development: Concepts, Principles, and Practices, Charles S. Wasson, Wiley Series in Systems Engineering and Management, 2006

Categories: Project Management

The Economics of Decision Making on Software Projects

Herding Cats - Glen Alleman - Sat, 06/10/2017 - 01:13

The classic paper  “Software Engineering Economics,” Barry Boehm, IEEE Transactions on Software Engineering, Vol SE-10(1), 1984, pp. 4-21. opens with a dictionary definition of economics as a social science concerned chiefly with description and analysis of the production distribution, and consumption of goods and services. 

A broader definition is

Economics is the study of how people make decisions in resource-limited situations. And those decisions are made in the presence of uncertainty.

Macroecon is about how people make decisions on a global scale. Microecon is about how people make decisions on a personal scale. This is about decisions for individuals and organizations. For software development, there are many decisions to be made. What Feature to develop next? Are we ready for the Release? Do we have enough time and money to develop the needed Features before the business needs to put those Features to work earned back their investment?

Since there are always limited resources - these are time, money, and people - we need some ability to make decisions in the presence of these limited resources. As well there is uncertainty on every project. Reducible uncertainty (Epistemic) and Irreducible (Aleatory). Reducible uncertainty can be reduced. Irreducible can not. We can spend money to reduce Epistemic uncertainty. Only margin can reduce irreducible uncertainty.

One model that is many times misunderstood by the agile community is the Cone of Uncertainty surrounding estimates as well as the technical and operational aspects of the project.

If your project's uncertainties are not being reduced in some declining manner - predefined manner - then you're going to be late and over budget and your deliverables are unlikely to work. So when those uncertainties are outside the upper and lower bounds of tghe Cone of Uncertainty, you'd better start looking for ways to fix the project.

Screen Shot 2017-06-09 at 5.37.16 PM
 So if we're going to be making decisions in the presence of uncertainty - somewhere along the horizontal axis of the project - with the resulting uncertainty range, we're going to need to estimate not only what the range should be for the phase of the project, but what effort and duration will be needed to reduce the variance of that uncertainty to keep that range inside the cone.

Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Making Conjectures Without Testable Outcomes Deadlines Always Matter What Happened to our Basic Math Skills? Root Cause of Project Failure
Categories: Project Management

Introducing Blockly 1.0 for Android and iOS

Google Code Blog - Fri, 06/09/2017 - 18:44
Posted by Erik Pasternak and the Kids Coding Team

Over the past five years, developers have created hundreds of projects with Blockly, our open source library for creating block-based coding experiences. These have ranged from education platforms like Code.org to electronics kits like littleBits and even Android app creation tools like MIT App Inventor. Last year, we also announced our collaboration with the Scratch Team to develop Scratch Blocks—a fork of Blockly optimized for creating coding apps for kids.

Today, we're finalizing our 1.0 release of Blockly on Android and iOS. These versions have everything you need to use Blockly natively in your mobile app, including:

  • Blockly's standard UI
  • Custom blocks, toolbox categories, and layouts
  • Functions, variables, mutators, and extensions
  • Code generation in JavaScript, Python, Dart, PHP, and Lua
  • Internationalization support (including for RTL languages)

While our 1.0 update today is focused on native mobile, we've also made several updates to the web project over the past six months. We've made major improvements to performance and testing, added more structured APIs, and improved touch support for the mobile web. In addition, we improved Internet Explorer and Edge support; Blockly is fully supported on IE10+.

We've done a lot of work to ease cross platform development, too! All blocks can now be defined by JSON, allowing a single set of block definitions to be used for web, iOS, and Android. Check out the documentationfor more details on all three platforms.

Get started right away with our iOS Codelab (Android coming soon)! To learn more about Blockly, check out the above intro video, visit our developer site, join our mailing list, or jump right into the code for web, Android, or iOS.

.blogimage img{ width: 100%; }
Categories: Programming

Making the Internet safer and faster: Introducing reCAPTCHA Android API

Android Developers Blog - Fri, 06/09/2017 - 17:15
Posted by Wei Liu, Product Manager

When we launched reCAPTCHA ten years ago, we had a simple goal: enable users to visit the sites they love without worrying about spam and abuse. Over the years, reCAPTCHA has changed quite a bit. It evolved from the distorted text to street numbers and names, then No CAPTCHA reCAPTCHA in 2014 and Invisible reCAPTCHA in March this year.

By now, more than a billion users have benefited from reCAPTCHA and we continue to work to refine our protections.

reCAPTCHA protects users wherever they may be online. As the use of mobile devices has grown rapidly, it's important to keep the mobile applications and data safe. Today, on reCAPTCHA's tenth birthday, we're glad to announce the first reCAPTCHA Android API as part of Google Play Services.

With this API, reCAPTCHA can better tell human and bots apart to provide a streamlined user experience on mobile. It will use our newest Invisible reCAPTCHA technology, which runs risk analysis behind the scene and has enabled millions of human users to pass through with zero click everyday. Now mobile users can enjoy their apps without being interrupted, while still staying away from spam and abuse.

reCAPTCHA Android API is included with Google SafetyNet, which provides services like device attestation and safe browsing to protect mobile apps. Mobile developers can do both the device and user attestations in the same API to mitigate security risks of their apps more efficiently. This adds to the diversity of security protections on Android: Google Play Protect to monitor for potentially harmful applications, device encryption, and regular security updates. Please visit our site to learn more about how to integrate with the reCAPTCHA Android API, and keep an eye out for our iOS library.

The journey of reCAPTCHA continues: we'll make the Internet safer and easier to use for everyone (except bots).

.gif img { display: block; margin: auto; max-width: 50%; } .gif2 img { display: block; margin: auto; max-width: 200px; }
Categories: Programming

Thinking About What to Call Team Members and Managers

Bob Sutton (@work_matters) tweeted this the other day:

Perhaps companies ought to stop using “IC” or “Individual Contributor.” It seems to absolve such employees from helping others

I retweeted it and we had some back-and-forth about what to call people i organizations.

Let’s eliminate these words for people who are not managers:

  • Individual Contributor: There are no one-person projects or efforts. Every work has at minimum, the person doing the work and the customer for that work. In what lifetime does a person work alone on anything in the organization?
  • FTE (Full Time Equivalent): FTE implies we have working units who are fungible with other working units who get paid the same amount. (Uh, no. Not at all. We have people who work.)
  • Resources: Resources removes our humanity. I have said before that people are resourceful. They are not resources.

We could call them any of these:

  • Team members
  • Employees
  • Staff (I used to use this word. I’m not so sure I like it anymore. But, I’m sure you can go back in this blog and show me places I’ve used it. I’m learning, just as you are.)
  • People

I like team members or people the best. That’s because I don’t see people working alone. Even in non-agile organizations. People work with other people. Even if they don’t collaborate together to finish the work. Even people who are part of one specific team often collaborate across the organization. Do let me know if you have a better idea.

Now, let’s go to the word, “Manager.” Managers are people and team members too. However, they float among different teams. Let’s take the first-level manager.

First-level managers are part of the team they manage, but not in the same way as the people doing the work of that team. First-level managers (project managers, functional managers, Scrum Masters) facilitate the team’s work. They serve the team.

In addition to the team they “manage” (no one manages people; managers decide on results and create the environment in which people/team members deliver results), these managers are also a part of other teams. Those teams might be people like them, such as functional managers who report to a Director or VP. They might be part of a team of project managers/Scrum Masters, etc. Those teams might not be explicitly defined in the org. However, effective managers use their peer group as a community of practice. They build relationships and learn what other people do.

Mid-level managers are often part of more explicit teams. They might be part of a program team, or a project portfolio team, maybe even a product line management team. They are often part of a team of the managers who report to them (their staff, “down” the hierarchy) and the managers they report to (“up” the hierarchy). Those teams might have a cadence of meetings to troubleshoot problems that prevent the first-level teams from delivering the results the org wants. These managers serve the organization, also.

Senior managers are often a team. They decide on the strategy together. They make financial decisions together. They set financial boundaries for the different work or departments. And, they also are part of their teams of managers “down” the hierarchy, their staff.

For me, team members are part of one feature team or work group. The managers use their small-world networks to build relationships and accomplish work throughout the organization. Managers are often part of several cross-functional teams, regardless of whether those teams have a name.

Hierarchy is a convenient way to organize, to draw boundaries around decision-making and financial responsibilities. I don’t have a problem with the words managers or team members. As with Bob Sutton, I have a problem with “Individual contributor” because no one works alone. We happen to pay people based on their “individual” contribution and that’s a leftover from the piece work days. Knowledge work doesn’t work like that.

We are all part of teams of some variety. If you think about names that are reasonable for your people (team members and managers), terrific. I certainly don’t have all the answers. (I wrote a little about what managers might do in agile organizations in several places here. I think the most recent post is What Development & Test Managers do in Agile Organizations.)

I only have a problem when we forget we are all people. Do let me know what you think.

Categories: Project Management

Thinking About What to Call Team Members and Managers

Bob Sutton (@work_matters) tweeted this the other day:

Perhaps companies ought to stop using “IC” or “Individual Contributor.” It seems to absolve such employees from helping others

I retweeted it and we had some back-and-forth about what to call people i organizations.

Let’s eliminate these words for people who are not managers:

  • Individual Contributor: There are no one-person projects or efforts. Every work has at minimum, the person doing the work and the customer for that work. In what lifetime does a person work alone on anything in the organization?
  • FTE (Full Time Equivalent): FTE implies we have working units who are fungible with other working units who get paid the same amount. (Uh, no. Not at all. We have people who work.)
  • Resources: Resources removes our humanity. I have said before that people are resourceful. They are not resources.

We could call them any of these:

  • Team members
  • Employees
  • Staff (I used to use this word. I’m not so sure I like it anymore. But, I’m sure you can go back in this blog and show me places I’ve used it. I’m learning, just as you are.)
  • People

I like team members or people the best. That’s because I don’t see people working alone. Even in non-agile organizations. People work with other people. Even if they don’t collaborate together to finish the work. Even people who are part of one specific team often collaborate across the organization. Do let me know if you have a better idea.

Now, let’s go to the word, “Manager.” Managers are people and team members too. However, they float among different teams. Let’s take the first-level manager.

First-level managers are part of the team they manage, but not in the same way as the people doing the work of that team. First-level managers (project managers, functional managers, Scrum Masters) facilitate the team’s work. They serve the team.

In addition to the team they “manage” (no one manages people; managers decide on results and create the environment in which people/team members deliver results), these managers are also a part of other teams. Those teams might be people like them, such as functional managers who report to a Director or VP. They might be part of a team of project managers/Scrum Masters, etc. Those teams might not be explicitly defined in the org. However, effective managers use their peer group as a community of practice. They build relationships and learn what other people do.

Mid-level managers are often part of more explicit teams. They might be part of a program team, or a project portfolio team, maybe even a product line management team. They are often part of a team of the managers who report to them (their staff, “down” the hierarchy) and the managers they report to (“up” the hierarchy). Those teams might have a cadence of meetings to troubleshoot problems that prevent the first-level teams from delivering the results the org wants. These managers serve the organization, also.

Senior managers are often a team. They decide on the strategy together. They make financial decisions together. They set financial boundaries for the different work or departments. And, they also are part of their teams of managers “down” the hierarchy, their staff.

For me, team members are part of one feature team or work group. The managers use their small-world networks to build relationships and accomplish work throughout the organization. Managers are often part of several cross-functional teams, regardless of whether those teams have a name.

Hierarchy is a convenient way to organize, to draw boundaries around decision-making and financial responsibilities. I don’t have a problem with the words managers or team members. As with Bob Sutton, I have a problem with “Individual contributor” because no one works alone. We happen to pay people based on their “individual” contribution and that’s a leftover from the piece work days. Knowledge work doesn’t work like that.

We are all part of teams of some variety. If you think about names that are reasonable for your people (team members and managers), terrific. I certainly don’t have all the answers. (I wrote a little about what managers might do in agile organizations in several places here. I think the most recent post is What Development & Test Managers do in Agile Organizations.)

I only have a problem when we forget we are all people. Do let me know what you think.

Categories: Project Management

Rediscovering testing with Horizon: Zero Dawn

Xebia Blog - Fri, 06/09/2017 - 08:20

Recently Guerrilla Games launched its newest and first open world game: Horizon: Zero Dawn. This got us thinking. Is game testing any different than testing 'regular' software? Together with Ana Barbuta, QA Manager at Guerrilla Games, we held a Meetup to find the answer to this question. In this blog post, we reflect shortly on how […]

The post Rediscovering testing with Horizon: Zero Dawn appeared first on Xebia Blog.

Budgeting, Estimation, Planning, #NoEstimates and the Agile Planning Onion

1127131620a_1

There are many levels of estimation including budgeting, high-level estimation and task planning (detailed estimation).  We can link a more classic view of estimation to  the Agile planning onion popularized by Mike Cohn.   In the Agile planning onion, strategic planning is on the outside of the onion and the planning that occurs in the daily sprint meetings at the core of the onion. Each layer closer to the core relates more to the day-to-day activity of a team. The #NoEstimates movement eschew developing story- or task-level estimates and sometimes at higher levels of estimation. As you get closer to the core of the planning onion the case for the #NoEstimates becomes more compelling.

03fig01.jpg (500Ă—393)

Planning Onion

 

Budgeting is a strategic form of estimation that most corporate and governmental entities perform.  Budgeting relates to the strategy and portfolio layers of the planning onion.  #NoEstimates techniques doesn’t answer the central questions most organizations need to answer at this level which include:

1.     How much money should I allocate for software development, enhancements and maintenance?

2.     Which projects or products should we fund?

3.     Which projects will return the greatest amount of value?

Budgets are often educated guesses that provide some approximation of the size and cost of the work on the overall backlog. Budgeting provides the basis to allocate resources in environments where demand outstrips capacity. Other than in the most extreme form of #NoEstimate, which eschews all estimates, budgeting is almost always performed.

High-level estimation, performed in the product and release layers of the planning onion, is generally used to forecast when functionality will be available. Release plans and product road maps are types of forecasts that are used to convey when products and functions will be available. These types of estimates can easily be built if teams have a track record of delivering value on a regular basis. #NoEstimates can be applied at this level of planning and estimation by substituting the predictable completion of work items for developing effort estimates.  #NoEstimates at this level of planning can be used only IF  conditions that facilitate predictable delivery flow are met. Conditions include:

  1. Stable teams
  2. Adoption of an Agile mindset (at both the team and organizational levels)
  3. A backlog of well-groomed stories

Organizations that meet these criteria can answer the classic project/release questions of when what and how much based on the predictable delivery rates of #NoEstimate teams (assuming some level of maturity – newly formed teams are never predictable). The high-level estimate is closer to the day-to-day operations of the team and connects budgeting to the lowest level of planning in the planning onion.

In the standard corporate environment, task-level estimation (typically performed at the iteration and daily planning layers of the onion) is an artifact of project management controls or partial adoptions of Agile concepts. Estimating tasks is often mandated in organizations that allocate individual teams to multiple projects at the same time. The effort estimates are used to enable the organization to allocate slices of time to projects. Stable Agile teams that are allowed to focus one project at a time and use #NoEstimate techniques have no reason to estimate effort at a task level due to their ability to consistently say what they will do and then deliver on their commitments. Ceasing task-level estimation and planning is the core change all proponents of #NoEstimates are suggesting.

A special estimation case that needs to be considered is that of commercial or contractual work. These arrangements are often represent lower trust relationships or projects that are perceived to be high risk. The legal contracts agreed upon by both parties often stipulate the answers to the what, when and how much question before the project starts. Due to the risk the contract creates both parties must do their best to predict/estimate the future before signing the agreement. Raja Bavani, Senior Director at Cognizant Technology Solutions suggested in a recent conversation, that he thought that, “#NoEstimates was a non-starter in a contractual environment due the financial risk both parties accept when signing a contract.”

Estimation is a form of planning, and planning is a considered an important competency in most business environments. Planning activities abound whether planning the corporate picnic to planning the acquisition and implementation of a new customer relationship management system. Most planning activities center on answering a few very basic questions. When with will “it” be done? How much will “it” cost? What is “it” that I will actually get? As an organization or team progresses through the planning onion, the need for effort and cost estimation lessens in most cases. #NoEstimation does not remove the need for all types of estimates. Most organizations will always need to estimate in order to budget. Organizations that have stable teams, adopted the Agile mindset and have a well-groomed backlog will be able to use predictable flow to forecast rather than effort and cost estimation. At a sprint or day-to-day level Agile teams that predictably deliver value can embrace the idea of #NoEstimate while answering the basic questions based what, when and how much based on performance.


Categories: Process Management

Android O APIs are final, get your apps ready!

Android Developers Blog - Thu, 06/08/2017 - 19:40
Posted by Dave Burke, VP of Engineering

Three weeks ago at Google I/O, we announced the second developer preview of Android O along with key themes, Fluid Experiences and Vitals, and highlighted our work towards a modular base with Project Treble. It was also an important milestone for us with the release of the first beta-quality candidate. We talked a lot about what's new in Android during the keynote and breakout sessions—if you missed the livestream, be sure to check out the full archive of talks here.

Today we're rolling out Developer Preview 3 with the final Android O APIs, the latest system images, and an update to Android Studio to help you get ready for the consumer release later in the summer. Watch for one more preview update coming in July that will bring you the near-final system images.

If you've already enrolled your device in the Android Beta Program, you'll receive an update to Developer Preview 3 shortly.

Make your app compatible with Android O

With the consumer launch approaching in the coming months, a critical first step is making your current app compatible with Android O. This will give your users a seamless transition to the new platform as it arrives on their devices.

If you haven't tested your app for compatibility yet, getting started is straightforward -- just enroll a supported device in Android Beta and get the latest update over-the-air, then install your current app from Google Play and test. The app should run and look great, and it should handle the Android O behavior changes properly -- in particular pay attention to background limits and changes in networking, security, and identifiers.

After you've made any necessary updates, we recommend publishing the compatible version of your app to Google Play right away -- without changing the app's platform targeting.

Enhance your app with Android O features and APIs

Extending your apps with Android O features can help you drive more engagement, offer new interactions, give users more control and security, and even improve your app's performance.

Notification channels and dots give you more ways to surface new content to users and bring them back into your app. Picture-in-picture keeps your app onscreen while users are multitasking, and autofill makes it simple for them to enter forms data and helps keep their data secure. Also check out adaptive icons, XML font resources, downloadable fonts and emoji, autosizing TextView, AAudio API, and many others. You'll also want plan your support for background execution limits and other important changes in vital system behavior for O apps.

Visit the O Developer Preview site to learn about all of the new features and APIs and how to build them into your apps.

Picture-in-Picture mode lets you keep users engaged while they are multitasking (left). Notification dots keep users active in your app and let them jump directly the app’s core functions (right). Get started with Developer Preview 3

Today's preview update includes the latest version of the Android O platform with the final API level 26 and hundreds of bugfixes and optimizations. You can download the final API 26 SDK from the SDK Manager in Android Studio, and Android Support Library 26.0.0 beta 2 from Google's Maven repository.

Together, these give you everything you need to develop and test your apps with the official Android O APIs. Once you've installed the final SDK, you can update your project's compileSdkVersion to API 26 to compile against the official Android O APIs. We also recommend updating your app's targetSdkVersion to API 26 to opt-in and test your app with Android O specific behavior changes. See the migration guide for details on how to set up your environment to build with Android O.

APIs have changed since the second developer preview, so if you have existing code using Android O preview APIs, take a look at the diff report to see where your code might be affected.

If you're developing for Android O, we recommend updating to the latest version of Android Studio 3.0, now available in the canary channel. Aside from great new features like improved app performance profiling tools, support for the Kotlin programming language, and Gradle build optimizations, Android Studio 3.0 includes build support for Instant Apps, an Adaptive Icon Wizard, and support for XML Fonts, and Downloadable Fonts.

Android Studio 3.0 includes tools for developing with Android O features lets you preview XML font resources in your app.

If you don't plan to use those features, you now have the option of developing for Android O using Android Studio 2.3.3 from the stable channel. Note that the tools for working with adaptive icons and downloadable fonts, and XML fonts are not available in Android Studio 2.3.3.

Publish your apps to alpha, beta or production channels in Google Play

Now that the APIs are final, you can publish APK updates compiling with, and optionally targeting, API 26 to your alpha, beta, or even production channels in Google Play. Publishing your O-targeted app during the preview lets you test compatibility on existing devices and push updates to devices running API 26 -- such as users who are enrolled in the Android Beta program.

To make sure that your updated app runs well on Android O as well as older versions, a common strategy is to use Google Play's beta testing feature to get early feedback from a small group of users -- including developer preview users — and then do a staged rollout as you release the updated app to all users.

How to get the preview update

Through the Android Beta program, developers and early adopters worldwide will soon be getting Developer Preview 3 on their devices. If you aren't yet enrolled, just visit android.com/beta and opt-in your eligible Android phone or tablet. As always, you can also download and flash this update manually. The O Developer Preview is available for Pixel, Pixel XL, Pixel C, Nexus 5X, Nexus 6P, and Nexus Player.

Thanks so much for all of your feedback so far. Please continue to share feedback or requests as we work towards the consumer release later this summer. We're looking forward to seeing your apps on Android O!

.logo img { float: right; margin: 0 0 10px 10px; width: 200px; } .parent { display: flex; justify-content: space-around; align-items: center; width: 100% } .child { width: 50%; } .child img { width: 100% } .captionx { font-size: 75%; margin: 5px 0 10px 0; } .assetx { width: 100% } .assetx img { width: 100%; padding: 0; margin: 10px 0 10px 0; }
Categories: Programming

Defining “Scaling” Agile, Part 4A: Sharing Agile Outside of Product Development

Note to my dear readers: As I write, I realize this series is growing. Thank you for your understanding in advance.

In Defining “Scaling” Agile, Part 4: Sharing Agile Outside of Product Development, I wrote about an independent workgroup with one stream of work. I used Customer Support as an example. Support has one stream: take in the tickets, work on the “most important” one first, see if you need to escalate and finish it. Everyone works towards the same goal.

What about if you work in a workgroup that has several streams of work? I’ll use HR as an example because HR often has these streams:

  • Benefits administration: retirement plans, health care, that kind of thing
  • Recruiting and hiring: how to find people and bring them into the organization
  • “Performance Management”: how to manage and improve the performance of the people in the organization. Don’t get me started on the value of this work. I have other drafts to address this wrong-headed assumption especially in an agile organization.

In that case, the workgroup rarely collaborates on the work. It’s possible that Customer Support collaborates on their work. However, the different people in HR do not tend to collaborate. It’s the same in Finance: Accounts Payable and Accounts Receivable are not the same thing. Depending on where Purchasing sits, they might be a different stream, also.

If the group wants a big picture of their work, this kind of a kanban board might help. Note that there are no WIP limits because the group does not collaborate. There is no interdependent work.

Each of these people might want their own board to show the details of their work, but that’s not this board.

There is no reason for—and it would not be helpful—for this group to have a standup. That would be a serial status meeting. They might want to monitor decisions to see if other people change their minds about what’s going on in their group. They might want to retrospect on how often they have Waiting work and what to do about it.

There is a difference between product development agile approaches and workgroup approaches. I have found that visualizing the work is the key for unlocking lower WIP limits and faster cycle time.

Yes, I have this board as an example in Create Your Successful Agile Project.

In a Marketing department, the product managers had their work and Marketing Communications had their work. MarComm had to produce videos of customer case studies, white papers, and testimonials. MarComm actually looked more like a product development feature team than the product managers did. The product managers had to continue to think about the product direction and how often they could replan. They each had their own boards (product management and MarComm). And, they put together a board much like the one for HR with streams on the bottom so other people could see bottlenecks.

If you work in a workgroup, you might need a board that shows the flow of work in your stream, and a different board that shows the overall group’s work at a higher level. There is no right answer.

Here are the posts so far:

I think I need another part about agile management and then I can talk about an agile business. I’m enjoying the rigor of my thinking. I hope you do, too.

Categories: Project Management

Defining “Scaling” Agile, Part 4A: Sharing Agile Outside of Product Development

Note to my dear readers: As I write, I realize this series is growing. Thank you for your understanding in advance.

In Defining “Scaling” Agile, Part 4: Sharing Agile Outside of Product Development, I wrote about an independent workgroup with one stream of work. I used Customer Support as an example. Support has one stream: take in the tickets, work on the “most important” one first, see if you need to escalate and finish it. Everyone works towards the same goal.

What about if you work in a workgroup that has several streams of work? I’ll use HR as an example because HR often has these streams:

  • Benefits administration: retirement plans, health care, that kind of thing
  • Recruiting and hiring: how to find people and bring them into the organization
  • “Performance Management”: how to manage and improve the performance of the people in the organization. Don’t get me started on the value of this work. I have other drafts to address this wrong-headed assumption especially in an agile organization.

In that case, the workgroup rarely collaborates on the work. It’s possible that Customer Support collaborates on their work. However, the different people in HR do not tend to collaborate. It’s the same in Finance: Accounts Payable and Accounts Receivable are not the same thing. Depending on where Purchasing sits, they might be a different stream, also.

If the group wants a big picture of their work, this kind of a kanban board might help. Note that there are no WIP limits because the group does not collaborate. There is no interdependent work.

Each of these people might want their own board to show the details of their work, but that’s not this board.

There is no reason for—and it would not be helpful—for this group to have a standup. That would be a serial status meeting. They might want to monitor decisions to see if other people change their minds about what’s going on in their group. They might want to retrospect on how often they have Waiting work and what to do about it.

There is a difference between product development agile approaches and workgroup approaches. I have found that visualizing the work is the key for unlocking lower WIP limits and faster cycle time.

Yes, I have this board as an example in Create Your Successful Agile Project.

In a Marketing department, the product managers had their work and Marketing Communications had their work. MarComm had to produce videos of customer case studies, white papers, and testimonials. MarComm actually looked more like a product development feature team than the product managers did. The product managers had to continue to think about the product direction and how often they could replan. They each had their own boards (product management and MarComm). And, they put together a board much like the one for HR with streams on the bottom so other people could see bottlenecks.

If you work in a workgroup, you might need a board that shows the flow of work in your stream, and a different board that shows the overall group’s work at a higher level. There is no right answer.

Here are the posts so far:

I think I need another part about agile management and then I can talk about an agile business. I’m enjoying the rigor of my thinking. I hope you do, too.

Categories: Project Management

Code Health: Reduce Nesting, Reduce Complexity

Google Testing Blog - Thu, 06/08/2017 - 19:24
This is another post in our Code Health series. A version of this post originally appeared in Google bathrooms worldwide as a Google Testing on the Toilet episode. You can download a printer-friendly version to display in your office.

By Elliott Karpilovsky

Deeply nested code hurts readability and is error-prone. Try spotting the bug in the two versions of this code:

Code with too much nesting Code with less nesting
response = server.Call(request)

if response.GetStatus() == RPC.OK:
if response.GetAuthorizedUser():
if response.GetEnc() == 'utf-8':
if response.GetRows():
vals = [ParseRow(r) for r in
response.GetRows()]
avg = sum(vals) / len(vals)
return avg, vals
else:
raise EmptyError()
else:
raise AuthError('unauthorized')
else:
raise ValueError('wrong encoding')
else:
raise RpcError(response.GetStatus())
response = server.Call(request)

if response.GetStatus() != RPC.OK:
raise RpcError(response.GetStatus())

if not response.GetAuthorizedUser():
raise ValueError('wrong encoding')

if response.GetEnc() != 'utf-8':
raise AuthError('unauthorized')

if not response.GetRows():
raise EmptyError()

vals = [ParseRow(r) for r in
response.GetRows()]
avg = sum(vals) / len(vals)
return avg, vals


Answer: the "wrong encoding" and "unauthorized" errors are swapped. This bug is easier to see in the refactored version, since the checks occur right as the errors are handled.

The refactoring technique shown above is known as guard clauses. A guard clause checks a criterion and fails fast if it is not met. It decouples the computational logic from the error logic. By removing the cognitive gap between error checking and handling, it frees up mental processing power. As a result, the refactored version is much easier to read and maintain.

Here are some rules of thumb for reducing nesting in your code:
  • Keep conditional blocks short. It increases readability by keeping things local.
  • Consider refactoring when your loops and branches are more than 2 levels deep.
  • Think about moving nested logic into separate functions. For example, if you need to loop through a list of objects that each contain a list (such as a protocol buffer with repeated fields), you can define a function to process each object instead of using a double nested loop.
Reducing nesting results in more readable code, which leads to discoverable bugs, faster developer iteration, and increased stability. When you can, simplify!
Categories: Testing & QA

Welcome New Host Matthew Farwell

We’re pleased to welcome Matthew Farwell to SE Radio. Matthew is a senior software developer at Nexthink in Lausanne, Switzerland. He has more than 25 years of development experience in C and then Java / Scala / JavaScript. His technical interests include programming languages, testing, code quality, and DevOps. Farwell is the creator of Scalastyle: the […]
Categories: Programming

Why Do Agilest Use Waterfall As Their Stalking Horse?

Herding Cats - Glen Alleman - Wed, 06/07/2017 - 16:48

Many agilest use Waterfall as the Boogeyman of software development. They show pictures of Design-Code-Test process, with no feedback loops, linear connections from beginning to end in the project.

Here in the DOD, Waterfall went away long ago as an acquisition strategy. Here's one of many guidance documents. Waterfall is dead, stop using it as a whipping boy. If you're doing waterfall in your enterprise IT, you're doing it wrong. Stop and learn how to apply modern techniques, one of which is Agile, but there are others. Google dod 5000.2 procurement agile to see how it's done.

Screen Shot 2017-06-06 at 8.40.21 PM

Related articles Who's Budget is it Anyway? Capabilities Based Planning Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management
Categories: Project Management

Finally Crossing the IoT Chasm?

From the Editor of Methods & Tools - Wed, 06/07/2017 - 16:14
I gave my first Internet of things (IoT) presentation over a decade ago. The response was overwhelming, and I have been waiting for the IoT tidal wave to land ever since. Strangely, it has not. Why not? Fast-forward through those ten years, and I have learned countless lessons. This presentation reviews the strengths and weakness […]

Defining “Scaling” Agile, Part 4: Sharing Agile Outside of Product Development

Here’s where we are so far in this discussion of what it might mean to “scale” agile approaches:

This is Part 4, where other functions want to use agile approaches. I’m calling this “sharing” agile. If these people are part of a program or a project, the product development team(s) have asked them to participate in an agile way. This part is about embedding (I’m not sure that’s the right word) agile approaches into other functions.

Some functions are workgroups where the people work mostly alone but might collaborate. Think of Customer Support for example. Customer Support has a single-function workstream. Other functional workgroups have multiple workstreams.


In Support, people take tickets (the incoming queue of work) often alone. They work their tickets until they resolve the ticket.
Here is a possible kanban board for what might happen as a flow for these tickets. The queue of tickets is all the way on the left. Notice that there are two possible Ready columns: Ready for ranking and Ready to Start.

Customer support teams might rank and rerank their work several times during a day. Certainly, they do so during the week. They rank some work so it’s Ready to Start. It’s possible that they have work In Progress, Escalated to some other team/group/function, in Test. Depending on what the product is, they might need a Deploy column and then the work is Done.

Customer support often discovers they have “inconsistent” cycle time. That is, some work takes very little time (as in hours), some work takes forever (as in weeks), and some is in the middle somewhere, in the form of days. In my experience, those cycle time ranges depend on what the Product Development teams released.

How could a Customer Support group use agile approaches? They don’t work together. They can’t possibly plan for the next week, never mind two weeks. (A Tier 3 support group might be able to plan for more time, but I doubt it.) There’s not much value in that much planning. There’s no value in standups although there might be value in walking the board to see if anything is stuck after some time period. I would walk the board for escalations, and sometimes, the escalations are the Support manager’s job.)

A Customer Support group can find much more value in managing WIP (Work in Progress), and managing escalations (their wait states and potential bottlenecks). And, there is tremendous value in retrospectives with root cause analysis. While the Support people might find problems in what Product Development released, they often discover that their processes need tweaking. Customer Support can take advantage of double-loop learning with their retrospectives.

When I ran a Tier 3 support group many years ago, I asked my staff if we could retrospect on a one-week cadence. For some huge problems, that was too often. But, it mostly worked. I checked the state of the escalations with the people who had escalated. I didn’t do this as a group because the problems were so different. That would have wasted everyone’s time. We did do once-a-week learning as a team. I was not smart enough back then to use a paper board. I used a spreadsheet.

Even I, with my love of paper boards, am not suggesting that all Support groups use paper boards. Support often requires electronic tools to be most effective. I do recommend that the group add enough columns to see their flow. Sometimes, Support groups take the escalations out and put them on a paper board for tracking, because the work cycles between different people and teams in those columns.

Agile approaches for workgroups are different than for teams. Teams have interdependent work. Groups have (mostly) independent work.

I’ll do another post about agile for workgroups with multiple streams. And yes, I have a chapter about agile approaches for workgroups in Create Your Successful Agile Project.

Categories: Project Management

Defining “Scaling” Agile, Part 4: Sharing Agile Outside of Product Development

Here’s where we are so far in this discussion of what it might mean to “scale” agile approaches:

This is Part 4, where other functions want to use agile approaches. I’m calling this “sharing” agile. If these people are part of a program or a project, the product development team(s) have asked them to participate in an agile way. This part is about embedding (I’m not sure that’s the right word) agile approaches into other functions.

Some functions are workgroups where the people work mostly alone but might collaborate. Think of Customer Support for example. Customer Support has a single-function workstream. Other functional workgroups have multiple workstreams.


In Support, people take tickets (the incoming queue of work) often alone. They work their tickets until they resolve the ticket.
Here is a possible kanban board for what might happen as a flow for these tickets. The queue of tickets is all the way on the left. Notice that there are two possible Ready columns: Ready for ranking and Ready to Start.

Customer support teams might rank and rerank their work several times during a day. Certainly, they do so during the week. They rank some work so it’s Ready to Start. It’s possible that they have work In Progress, Escalated to some other team/group/function, in Test. Depending on what the product is, they might need a Deploy column and then the work is Done.

Customer support often discovers they have “inconsistent” cycle time. That is, some work takes very little time (as in hours), some work takes forever (as in weeks), and some is in the middle somewhere, in the form of days. In my experience, those cycle time ranges depend on what the Product Development teams released.

How could a Customer Support group use agile approaches? They don’t work together. They can’t possibly plan for the next week, never mind two weeks. (A Tier 3 support group might be able to plan for more time, but I doubt it.) There’s not much value in that much planning. There’s no value in standups although there might be value in walking the board to see if anything is stuck after some time period. I would walk the board for escalations, and sometimes, the escalations are the Support manager’s job.)

A Customer Support group can find much more value in managing WIP (Work in Progress), and managing escalations (their wait states and potential bottlenecks). And, there is tremendous value in retrospectives with root cause analysis. While the Support people might find problems in what Product Development released, they often discover that their processes need tweaking. Customer Support can take advantage of double-loop learning with their retrospectives.

When I ran a Tier 3 support group many years ago, I asked my staff if we could retrospect on a one-week cadence. For some huge problems, that was too often. But, it mostly worked. I checked the state of the escalations with the people who had escalated. I didn’t do this as a group because the problems were so different. That would have wasted everyone’s time. We did do once-a-week learning as a team. I was not smart enough back then to use a paper board. I used a spreadsheet.

Even I, with my love of paper boards, am not suggesting that all Support groups use paper boards. Support often requires electronic tools to be most effective. I do recommend that the group add enough columns to see their flow. Sometimes, Support groups take the escalations out and put them on a paper board for tracking, because the work cycles between different people and teams in those columns.

Agile approaches for workgroups are different than for teams. Teams have interdependent work. Groups have (mostly) independent work.

I’ll do another post about agile for workgroups with multiple streams. And yes, I have a chapter about agile approaches for workgroups in Create Your Successful Agile Project.

Categories: Project Management

D-Day

Herding Cats - Glen Alleman - Wed, 06/07/2017 - 02:35

9c361277fee4688b9f2070121059f4bc

 

Categories: Project Management

Uncertainty in Planning/Budgeting/Estimating

Uncertainty is a reflection of human’s ability to think about and then worry about the future.  The future, whether tomorrow or next week generates cognitive dissonance because we are afraid that what will happen will be at odds with our mental model of the future. Budgeting, estimation, and planning are tools to rationalize away uncertainty; however, they have a complicated relationship with uncertainty.  For example, in some scenarios some uncertainty helps to prove the veracity of an expert, and in other scenarios uncertainty can generate cognitive dissonance with the assumption of certainty built into budgeting, estimation, and planning tools organizations use.

In work entry processes (both at the portfolio and team levels), uncertainty is a double edge sword impacting which work items get done.  Having participated in many portfolio meetings, certainty is often used as a tool for persuasion. Revenue and cost projections are often portrayed as facts that just have not occurred yet.  When a product owner or stakeholder expresses the often express certainty to generate energy and emotional contagiousness.   The expression of certainty about the outcome and value of a piece of work is often useful to influence allocating scarce money, people, and resources.  A more effective approach generally is to express the uncertainty in the process breaking down the façade of certainty.  

 “Persuasion research reveals that in some situations people can make their own message more persuasive by explicitly noting that they are unsure about what they’re saying!”

Some degree of uncertainty, when delivered by an expert, is more believable than absolute certainty.  Most portfolio allocation discussions are more apt to follow the expert opinion in which uncertainty engages listeners to think more deeply about the work they are considering.  The use of uncertainty as a focusing tool only works if the uncertainty is being delivered by a perceived expert and in a scenario where participants trust each other.  However, trust and expertise do not always exist (nor are they always possible to generate), leading organizations to address uncertainty in a different manner.  Techniques are used to provide a framework for identifying and accounting for factors that generate uncertainty but they do not make it go away. One technique of this type is weighted shortest job first (WSJF).  WSJF boils several factors into a single number.  Uncertainty is addressed by breaking pieced work into smaller pieces and getting feedback quickly.  WSJF and other techniques such as cost-benefit analyses often generate a blindness toward uncertainty, leading to the need to build techniques for monitoring and mitigating uncertainty into the budgeting, estimation and planning process. 

  1. Add contingency.  Uncertainty drives the need for contingency.  The amount of contingency is a proxy for uncertainty.  The equation is: the more uncertainty, the more contingency is needed. Phil McKinney, of the Killer Innovations Podcast,  suggests dealing with the uncertainty of innovation by keeping some budget unallocated to generate feedback cycles.  Contingency is similar to avoiding planning people to be 100% utilized on specific tasks (stuff always happens).
  2. Break the work into smaller increments.  It is easier to be certain about the future if the future is tomorrow or next week and less easy to be certain if the future is a few months from now.  Smaller increments increase certainty by generating feedback which can be used to stay on course. The problem with small increment is that they tend not to follow budgeting cycles. Also, remember that while shorter time horizons increase certainty, they do make uncertainty go away.  A black swan can always appear and rewrite an organization’s basic assumptions.
  3. Leverage Monte Carlo simulations. Monte Carlo simulations use mathematical modeling techniques to account for uncertainty (risk) to derive the range of possible outcomes and the probability of each outcome.  This injects the idea of a range of possible outcomes into the conversation.  The range outcomes and the probability of each possible outcome is a great tool facilitate a conversation of uncertainty.
  4. Measure promised and expected outcomes and compare those outcomes to what actually happens. While this a retrospective technique, people involved with budgeting, estimation, and planning often are segregated from delivery personnel and need measured feedback to improve how they do work.

Uncertainty affects what gets done and how we budget, estimate, and plan.  Building uncertainty into how we work makes more sense than pretending uncertainty does not exist.

 


Categories: Process Management

Agile Project Management Methods

Herding Cats - Glen Alleman - Tue, 06/06/2017 - 22:57

There is a lot of unsubstantiated claims going around about how agile should or should not be applied. How estimates are or are not needed. How the team should or should not be managed.

From the point of view of Software Intensive System of Systems, here's how we've learned to manage development using Agile. These projects are NOT de-minimus, they are mission critical. Many times they are National Assets. Most times there ar tangible capital assets to the corporation - not just expenses. They are always at the enterprise level. They have deadlines. They have not to exceed budgets, they have emerging requirements built on baselined Capabilities. The document below is a Chapter in The Story of Managing Projects: A Global, Cross-Disciplinary Collection of Perspectives showing how to manage in the presence of uncertainty using agile methods.

PM Chapter on Agile IT Project Management Methods from Glen Alleman
Categories: Project Management