What I do

Hint: I’m more than a software developer

Software delivery is hard. There are many tiny details that need to be considered, technologies to master, and business cases to Continuous Integration Workflowlearn. Delivering working software is a huge challenge.

It’s also expensive. A small software development team (2 good developers and a project manager) can easily cost $250,000/year.

Finally, it’s risky. Studies have shown that most projects are 6 to 12 months behind schedule and 50 to 100% over budget.

We try to deliver software:

  1. With high quality
  2. On budget
  3. On time

I present topics and give talks to help developers and Agile Managers hit those goals.

This site serves as an information resource for .NET Developers and Agile Managers to get a glimpse into how I work in my capacity as an SDLC auditor. This serves as a starting point for further conversation.

On the .NET Developer side, I focus on two topics:

  • Staying on track
  • Keeping the quality high
  • Working with management

On the Agile Management side:

  • Be efficient (or ruthless)
  • Measure and adjust

There are also some fun articles on the .NET Micro Framework and embedded hardware programming. It’s a side hobby of mine and I love sharing what I’ve learned.

MCSD.NET

 

Latest Post

Internet of things and social participation

The internet is a representation of our virtual world. We used to shop, bank, celebrate birthdays, buy cars, get medical advice, and enjoy music in the physical world. We all recognize, for better or worse, many of our old physical world interaction are now moving to the virtual world. Today, people are comfortable making purchases and moving their social interactions to the web.

Social media changed the way we interact with each other and companies we use. We have an unprecedented number of channels to interact socially. This has dramatically changed our expectations on interactions. We understand that a “Happy Birthday” message on Facebook is meaningless. However, a Twitter interaction with a company you’re having problems with is very valuable. LinkedIn is usefully for finding jobs. Pinterest is good to find new products and ideas.

The Internet of Things (IoT) is how we will take the next step towards connecting our physical world to the virtual world. IoT is the idea that physical devices will be connected to the internet to publish all sorts of sensor data. Your smartphone already publishes location data. Your TV publishes what shows you watch and record. Your interactions will smartphone apps and website are tracked and measured in amazing detail. Even your health information, through activity tracking devices, is collected and stored on-line.

This isn’t just limited to consumer devices. Industrial machinery publishes how well it’s operating. Many cash registers send information about which items were just sold. Government sensors already collect massive amounts of data for on pollution data, traffic, public transportation times, and others.

Just like social media changed the way we interact, IoT needs a social component. IoT social participation will enable the collection of massive amounts of physical data. All sorts of data needs to be collected; noise, movement, pollution, crowds, vibrations, etc. This will enable a new social participation analytics economy. To name a few, we could:

  • Better predict earthquakes
  • Track noise pollution
  • Find which restaurants have the shortest wait times
  • See which hiking trails are blocked

Social participation in data collection will have a transformative effect on social efforts for change. Social media allows people to promote change with their voices. Social participation will allow people to enforce change with data. We will be able to show what is actually happening in the real world. It’s hard to argue with actual data compared to the aggregate voice of customer sentiment. Sentiment is important, but data is reality. For example, a neighborhood might be complaining about a wind turbine making noise. The sentiment is easy to measure. They’re unhappy. However, by measuring noise levels over time throughout the area, we could have actual data on noise levels. We may (or may not!) find there is no additional noise compared to baseline. This would give definitive data on which to take action.

The social participation of the data collection is critical. There are no interested parties. Everyone is collecting and sending in raw data. Just like the internet and social media, the Internet of Things and social participation could become truly transformative.


Marginally Useful Driven Development

Why have we seen the proliferation of so much “SOMETHING Driven Development” in Agile? A quick internet search for “Driven Development” came up with this list:

  • Test
  • Feature
  • Perceived Value
  • Behavior
  • Design
  • Career
  • Hypothesis
  • Support
  • API
  • Problem

The reason most of these exist is to identify what to build and assign value to that effort. This is because of what many companies actually do: Marginally Useful Driven Development (or MUDD).

MUDD is the process by which requirements are created in several ways:

  1. In the absence of any real business need
  2. In the absence of any real business or competitive analysis
  3. In the absence of concern for cost or value
  4. Trying to keep stories in the backlog to appear busy

Identifying MUDD

Identifying MUDD takes a little practice. However, the fundamental rule is requirements and directions need to come from the business. The business is responsible for defining “what” to build and “why”. They are responsible for communicating the business need and the value of what is being built. They’re also responsible for researching marketing risk for user adoption for a particular product or feature. You can identify MUDD if there is no market value and risk analysis. The best way to identify MUDD is to identify the source of the product requirements. If they are sourced from the development team, you’re likely in MUDD.

My MUDD Persists

Rarely do development teams question if a feature request or product is MUDD. A full backlog equates to job security for developers. So, there’s no incentive to question the value of features. In addition, if the developers are working, business and management don’t have to get involved. This makes MUDD very difficult to address.

Clean out the MUDD

Teams and individuals which raise MUDD concerns are your most valuable employees. They care about the product and company. The goal of identifying MUDD is to remove it from the backlog. This creates space and pressure to be creative and do the market research to identify actual customer needs. Listen to the MUDD identifiers, justify the existence of the feature requests, and prioritize stories with the most customer value. You will have an organized team working on something of value. People will work much harder on something if they know it’s useful and has real value. In the end, you’ll deliver a higher quality product which meets the needs of the customers and have happier employees.


Start doing Agile with retrospectives

The number one question regarding Agile I get is this:

Can you send me some links, blogs, references on how we should do Agile?

Let’s ignore the fact I make my living doing Agile coaching and software development for a moment. Let’s also ignore the fact that you can’t learn to fly a plane by reading blog posts. Let’s also ignore the fact that there are countless reasons why one book/blog/video might not be the best solution for your situation. Every company is different and requires a custom approach to implementing a new management process. I mean that. Agile is a new management process. It requires focus, dedication, leadership, time, and money. There’s no switch you can flip to become Agile. It’s a process which needs experienced leadership for success. That being said, there is something you can do today which will help you. You can Start doing Agile with retrospectives.

A retrospective is not a post-mortem

A retrospective is not a post-mortem. A post-mortem is what you do after something has died. Maybe, the project failed or you lost a major client. That’s the time for a post-mortem. An exceptional event happened which needs focused analysis.

The Process

I do retrospectives every Friday toward the end of the day. It’s a look back at the past with an eye toward the future. The retrospective gives the team the opportunity to discuss two topics:

  1. What went well
  2. What needs improvement

This allows the entire team to discuss areas of success and areas of improvement. Once everyone has had a turn to give input and ask for specifics, everyone votes. Everyone gets one vote on the “what needs improvement” list. The top item, sometimes two, are taken.

I have a simple script I read before every Retrospective. I have it memorized now:

This is the retrospective. We are here to discuss how we work together as a team. The focus is on process and how we work together. It is not a re-cap of the work completed this week. Everyone will be asked to comment on two things. (1) What went well, and (2) What needs work. If you don’t have anything to say, you can say “pass”. Please don’t struggle to comment.

What that reminder out of the way. I call on the first person:

Me: Tom, what went well?

Tom: Ummmm…..

Me: If you don’t have anything you can say “pass”.

Tom: Pass

It’s inevitable.

Once we get through everyone, we get this.

– What went well

Communication

Improved velocity

Agile is working

– What needs improvement

Build server is broken

QA is over taxed b/c we get work to them late

Tommy is bored

Then we vote. Everyone who is part of the delivery team gets a vote. You usually wind up with a clear winner. If not, the scrum master breaks the tie. In this example, let’s pretend “Build server is broken” was the selected.

The outcome

The retrospective now has two final tasks:

  1. Agree to fix the problem
  2. Assignment of the resolver

Most of the time, the person responsible for resolving the issue is the scrum master or project manager. So, to fix the “Build server is broken” problem, the cause of the issues must be determined and appropriate action needs to be taken. This could include assigning new duties to a person. Maybe, Tommy? He seems to need something to do.

Final thoughts

The retrospective is the single most valuable Agile practice. It’s the vehicle which enables teams to grow and improve. Having a forum where team members can praise success, discuss issues, and agree to resolve those issues will dramatically increase team productivity and morale. They now become the owner of their process. You can call your management process whatever you want. But having retrospectives is simply a good management practice.

 


Older Entries »