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 learn. 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 project are 6 to 12 months behind schedule and 50 to 100% over budget.
We try to deliver software:
- With high quality
- On budget
- 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.
Before we talk about how and why agile fails, let’s talk about what Agile promises. Agile and it’s supporters make promises. These are:
- Reduced risk
Agile promotes visibility by merging responsible business units into one team. The team is mandated to deliver the maximum amount of business value by following a general set of guidelines. All team members are responsible for delivering the value in collective ownership model. For example, this enables sales will know early when there is a problem fixing a certain bug. Also, marketing will know why a particular feature request will take 6 months. The cross-functional visibility allows better understanding of the cost/feature ratio.
Teams are tasked with delivering an agreed upon number of stories at the end of each iteration. The stories must be complete at the end of the iteration. This means “defect free” to the best ability of the team. The technical side of Agile asks for Continuous Integration servers, Unit Testing, QA oversight, and other processes to ensure the code quality is kept high. The commitment to code quality keeps customer satisfaction high and costs low. This is often cited as a major need for an Agile implementation.
Agile accepts that change is inevitable. Agile team members are encouraged to embrace change as opportunity for improved user satisfaction and market competitiveness. Developers are especially encouraged, as change allows them to seek new ways to solve new problems.
Agile businesses reduce risk by better forecasting of budget and product delivery. An agile company has a better chance of delivering a product which matches the customer needs. Technical risk are mitigated by finding out why doesn’t work early and continually improving the technology and surrounding processes.
This all sounds great. Your company would be crazy to not adopt Agile practices. Recently, there has been a backlash against agile management practices. This backlash is caused directly by the failure of an Agile implementation. The ruthless truth, it sometimes fails. I’ve worked with both successful and failed Agile teams. Also, I’ve implemented Agile both successfully and unsuccessfully. In the spirit of collective ownership, I own part of that failure. If it’s so great, why do Agile implementations fail? Here’s what I’ve seen.
Why Agile Fails
Weak business adoption
Yes. This is #1. Agile is a business mindset. Often, business leaders (C-suite and middle management) view Agile as “something for the IT department”. However, business members need training and coaching just like everyone else. This is a major problem for C-level executives and owner/founders. Their mindset might not be malleable to changing their behavior. Without adoption at the top-level, business leaders become Agile saboteurs. Agile is for the business. We strive to deliver the best possible product which meets the needs of our customers. Business leaders need to adopt and modify their practices to support the goal. The practices are the same for everyone else; work in iterations, work transparently, set goals, commit to your goals, etc…
Here are a few key identifiers of when business leaders need help with adoption:
- Lack of input on product features
- Lack of understanding on product functionality
- Weak knowledge of product backlog
- Poor knowledge of product roadmap
- Changing iteration goals
- Lack of participation in ceremonies (stand-ups, planning, retrospective)
- Distracted during ceremonies (using text, email, etc.)
All of the issues above point to your business leaders needing coaching.
Poor corporate culture
This is everything for which the CEO or founder is directly responsible. Agile needs a specific culture or a top-level mandate for cultural change. Corporate culture has a direct effect on the success of Agile teams. Some the major issues which are cultural in nature are:
- Delaying meetings
- Excuse making
- Distractions during meetings
- Finger pointing
These cultural issues point to a larger problem. They prevent adoption of the four Agile promises.
The cultural push back
Agile is still on its early learning curve for most organizations. The technical practices are well-known, easy to adopt, and show success. Code quality keeps getting better resulting in higher customer satisfaction. However, the business and cultural practices are fighting back. The greater transparency, collective ownership, and goal setting principles are breaking down the isolation walls of middle and senior management. Now, the business leaders are being:
- Asked to account for their time
- Challenged on their decisions
- Challenged to justify their directives
This is a good thing! Employees are working together. They’re looking at the greater picture and thinking about the customers and the business. They’re looking for you to be a leader not just a boss.
I suggest that C-level executive and owner/founders evaluate themselves. The traits which are most amenable to Agile adoption are:
- Book reading… blogs don’t count!
- Excellent time management
- Passion for excellence
The future of Agile
As an Agile coach, I see two ways forward:
- Only take engagements with a high-chance of success
- Treat Agile as a technical practice
It’s easy to do a one-day assessment of an organization. Develop an honest and full report on the success-likelihood of Agile for their organization. I’m currently suggesting that all companies I work with to go through this process. A report which says “No” is much cheaper and less painful than a failed implementation. I detail who is likely to obstruct the process and why. I also suggest ways to address the problem.
Agile as a technical practice
An organization or team can benefit from the technical practices of Agile even if the answer is “No” from a corporate assessment. Engaging with a client and defining the parameters of the Agile implementation can return a measurable benefit to the organization. This won’t help with visibility or reduced risk, but it will result in happier customers and developers.
Agile coaches need to communicate Agile as a spectrum. We need to convey the concept Agile as a continuum on which a particular company may only get to 10% Agile. We need to speak of Agile not as a business transformation process (although it can be!) but rather as an option to solve pain. How much Agile-surgery a company can tolerate depends on the leadership of the company.
When we start thinking of Agile this way we don’t measure our success in terms of “Is the company Agile?” Rather, we measure our success in terms of how much pain did we reduce and how much happier are the people. That what the first Agile principle is all about. We value “Individuals and interactions over processes and tools”.
You can probably tell by now that I love marquee effects. My latest code example uses only a single pin on a Gadgeteer mainboard. Most people would use a bit shift register such as the 74HC595 for the effect. However, you can also use a very cheap CD4177B. It’s a 10 pin progressive output IC. So, every time you clock the chip, the output moves to the next pin. Once you hit pin 10, it wraps backs to pin 1. This makes is incredibly easy to create a marquee effect. You only need to provide power the chip and pulse the clock at the rate you want to move the LED light.
To be honest, there’s no need to use a microcontroller here. I also put the same thing together using a 555 timer instead.
Here’s a video of it working:
The wiring looks like this:
I have a potentiometer to control the speed of the pulses. The timer changes it’s interval based on the potentiometer value and pulses the clock pin. This is pretty much the easiest project next to a simple blinking light one can do.
The LED Marquee using CD4017B code is here: