Do What Demonstrates the Highest Possible Value and Be Prepared to Tell a Story About It

Requirements and fixed plans are a tricky breed. When you're on deadlines and things are either slipping or getting behind or, say, you're developing some technical debt from which you can't currently escape, go ahead and start thinking of what you can do NOW that will add the most value to the system OVERALL. Always think of the overall, even when you're in the weeds. My project for example has about 8 items due this week and we are scrambling to do as much as we can. Throughout the day we re-plan and reprioritized based on where we're at and where we have to go. We always keep in mind "What's the story", meaning do we have a good story to tell management or the customer about what we're doing. We don't want to be careless or wasteful so we think of what's the best next thing to to and we do it. After we're done with it we repriorize and adjust. New bottlenecks, roadblocks, and impediments are getting removed all of the time and freeing up new capabilities. There are SO MANY dependencies in a software system or software project that you could NEVER Gantt chart it all out and execute a waterfall process successfully; attempting to do so would be crazy.

At any rate, we're having some fun building this Business Intelligence application for the customer that takes from about 5 systems and integrates them into one. It's hard, challenging work but we have a pretty good approach: we've isolated the "pulling data" problem from the "unifying and normalizing data" problem from the "present the data" problem. We now have a very solid foundation that can create some real velocity within our team. One guy on the pulling, back-end, and automation, and a couple of guys on the front-end making it look real nice.

The Real-Time Burndown

Probably the holy grail of software development or any project for that matter is to know how long you have to go until you're going to be done. This is a very important metric from a lot of angles.

In software as tasks get brought into scope for a current sprint or release, this spikes up our hours. We might think something will take a long time and it impacts our perception of completion time. But as we dig into our tasks and re-estimate how long they will take to complete, we get more accurate. By providing a system to keep estimated hours until completion at the aggregate for a release we can be in control as a team. All of the stakeholders can watch as things ebb and flow and hopefully the work is burning down in time to meet our deliverable milestones. By looking at big tasks (sorting by largest hours to complete) we can see our risk in the project. Start the big stuff now and knock it down fast.

The Release Manager is the Product Owner

What's a release manager? A marketer. A public relations fellow. Someone that cares both about the customer AND the product development team but in no specific order. This person is the best possible person you could have on your team or company. They can turn a bad project into a good one and a good one into a bad one. If you have someone acting in a release manager capacity that is either A) all about the requirements or B) all about giving the customer everything they want regardless of cost, you're in trouble.

Train people in this role how to help you out, provide air-cover, and also how to serve the customer. If you are the guy/gal responsible for delivering the product find someone who complements you very well and understands how to communicate, deflect, and the like. I'm not yet sure if the Release Manager needs to be technical in a software project but I believe the answer is definitely yes, since if they aren't they can't deflect and backlog as necessary, that would end up falling to you.

Be Fair

How can you be fair in work? How can you kindly deal with other, hard-to-deal with people? Consistency is probably the number one way. But what if you're consistently a jerk, or consistently unfair? I believe that by being consistent in our decisions and ways of thinking (your process), people will have a way to view your inner world and question your—sometimes possibly unfair—intentions. Be open, be a book. Expose your reasons and why you're doing what you're doing and you'll get better at doing it.

Date-Driven Development

"What are we going to get and when?" Not the easiest question to answer sometimes. When the requirements are vague and the climate is tough, you still have to be able to operate. Understand how to deliver the minimum possible deliverable that qualifies as that requirement by name. Try not to get into too many details with the highest-up sponsors. If you do get into details with them, renegotiate the dates and bring them into your process.

Planning Shouldn’t Be a Chaotic Process but Often Is – Without the Right Authorization

Why? Because it involves the commitment of others. You can create a plan for yourself; that's fine. But it almost always—especially in business—has dependcies on others. If you are the planner, the doer, the leader, the driver, the actor, then oftentimes your presence and energy makes people uneasy. They see you as frazzled, needy, and chaotic. But are you? Yes, but only because that is your perception. As a leader and doer, you have to be able to be calm, cool and collected and communicate effectively with others about what you need from them. If you have a plan and your hell-bent to execute on it you'd better be very careful about how you come across to and approach others. You have to be patient and communicate very well. You have to sell them on what you're doing and why, how they're involved and necessary and how their lack of commitment or engagement impacts the organization. When you get push-back or lack of cooperation from people it is your job to do two things A) try to convince them to partake B) find alternate courses of action to continue to drive the program forward and get commitment and C) be ready to communicate about lack of participation and engagement to senior leaders. Doing Item C will most likely give you more power to engage with these people. Having support of your senior leadership gives you the power of coercion rather than influence. This "real" power can help you get very far in organizational projects.

This blog has moved

This blog is now located at http://kickmajorbooty.blogspot.com/.
You will be automatically redirected in 30 seconds, or you may click here.

For feed subscribers, please update your feed subscriptions to
http://kickmajorbooty.blogspot.com/feeds/posts/default.

Technical and Non-Technical People; There’s a Big Difference

This is a huge distinction in people's minds in business. Technical people are the engineers, the doers, and often the coffee-getters of our organizations unfortunately. Non-Technical people wind up being the leaders and managers. But why?


In a way in business, it's a very large penalty to be capable of doing the work. Yes, there's an entire body of "work" in management but there are some people out there that really don't do shit and don't know shit; they don't add value. These non-technical people somehow find a way to become the managers and leaders of our organizations. But why and how?


In my opinion, you either know how to do the work or you don't know and you wind up telling people what to do. Business is a crazy world that's centered in strange ideas of power.

Is My Project an Unintentional Agile Turnaround?!

After a very long and trying month and a half on a new project, it may be turning around to a success?!!! Could it be?! Maybe. The suggestion was even made by a senior coworker today of having "more than weekly" recurring meetings with the client to sync. I joked about having "Daily Two-Hour Standups". We're in a development rhythm (finally) and that is really satisfying. I'm really the only developer, though. That's been hard. Really long hours. 12 hour days are typical. Our project and delivery schedule is as follows: Plan Mondays and deliver Fridays. I twisted arms to add a ton of risks to our risk register today. Seems very simple moving forward but it's been hell getting here. I'm not sure how many teams work the way we're working. We have a very difficult problem we're solving; many moving parts and tons of senior-management pressure. Dates and deadlines. It's fun at the moment and I hope going well. I have a huge deliverable tomorrow and I've learned so much on this project about data movement, ETL, and SSIS. Also about people and leadership. Roles, and stepping down when you can. Let quality people be quality; let them help you out.

I'm designing an automated business process that removes 204 manual hours of work monthly. That's fun and satisfying.

Mind the WIP and the Whipping

Two skills for PMs. Make sure that the work in process is going well and that impediments for the workers are removed. That is your job. Another job is to watch how much you are whipping your employees. Assume they are smart and good; doing a good job, with good intentions. Guide and lead them. Mind the whipping and don't whip too much. Choose carrots (vision and leadership) over sticks and whips.

The Demo Could Happen Any Minute

Don't be a slacker. Be very clear on what you're doing and why. Who knows, the customer could join you right now and want to see what you're doing and why!!!! Be prepared.

No matter how paranoid you are, you’re never paranoid enough.

Afraid someone is watching you? They probably are.

In a computer system, anything that did once exist (all events and data) could be logged into a database and analyzed either now or later. This data could be used against you but it could also be used for good. How so? In making our software better! But what is the cost?

The more parts of our software that get "instrumented" (hooked up to log actions into a database), the more at risk we are for losing our privacy. And A LOT of the parts of our software are getting instrumented and hooked up to online databases. You could build your house into Fort Knox, but you need a data Fort Knox as well and things like "The Cloud" conflict and compete with that. Many companies today instrument their software in order to learn how people use their software. They use this data to make the software better; but there is a very big cost to this! This same data could be stolen or subpoenaed and used against you. Not exactly what you want.

In short, be very, very careful and very, very paranoid of what you're doing on your computer and online … they could be (and probably are) watching you!!! ; )