I work in an environment that is somewhat dominated by a project governance mentality. What does this mean? What it means to me is this – that our diligence is focused on spending rather than on asset creation. Why is this significant? Because it changes how we focus the decisions in the process of software development.Continue Reading
Articles by Rich
What I Have Done
Recently I have had to look back on my career and remind myself what I have done. I am leading a challenging project, and at times it feels like I have team members and customers projecting their expectations for how the work will be executed. Sometimes amid the cacophony of voices, I have to remind myself that I am capable of bringing the team to consensus around strategic decisions. Continue Reading
Product Portfolio Management
Product Portfolio
If you want to manage a portfolio of software products, it is necessary to understand the organizational goals that are met by those software products. The product portfolio is a vehicle for understanding the ongoing investment in development or deployment of software assets. It requires an ability to measure the value of software assets separate from their cost (rarely done in industry today), and an ability to measure the cost of ongoing support and maintenance of software product. Continue Reading
Agile Is Not For Everyone
OH: (on twitter)
“Convinced. Everyone that says “agile doesn’t work” or even “agile doesn’t work for us” just doesn’t know what it means to be agile.”
I read this on Twitter over the weekend (12/17/11). It really got me fired up. Mind you, I am an avid agilist. The point is, that some situations are not particularly suited to derive benefit from agile practices. Continue Reading
Why are we doing that?
Take anything. Any activity. Any Practice. Any Standard. Any Method. Ask the question “why?” – with fresh eyes, take a long hard look at why we are doing it. Now, ask yourself if the “why” is being accomplished. Ask yourself if you even know how to measure the benefits you originally sought. Ask yourself if all the acitivities, practices, standards, methods and other things we do make sense together.
Dogma is powerful. Questioning is more powerful. Dogma is required like training wheels. We need something to help us get up and rolling. Once we are rolling we need to get rid of the training wheels so we can go fast. Continue Reading
Take Your Team to a Drag Race
One thing that I have noticed at the beginning of a project is that there almost always appears to be confusion. Confusion about mission. Confusion about terminology. Confusion about what is important. Confusion about roles and responsiblilities. It feels bad, it looks bad and it smells bad.
It’s like what drag racers do before a run. They used to pour bleach on the tires and spin the drive wheels, creating massive amounts of foul smelling smoke. The purpose of this exercise is to heat up the rubber, so on the actual run, the tire are already super sticky and get traction and the car launches like a “hole shot” down the strip. There is a science to this, but it feels, looks and smells bad.Continue Reading
Project Pork Prevention
Why is it that the customer in corporate software projects seems to want to pack the scope of every project with capabilities of dubious value, in the same way that our congressional leaders try to pack important bills with “pork”? Why do organizational leaders try to take a well funded project or initiative and use it as a means of funding their personal management agenda? Because like congress, if they can construe their agenda as essential to the completion of some important project – they bring the business value (pork) home to their department. They can use the project as a vehicle to accomplish things that ensure that they get their bonus. These leaders act as though their incentives are more important than the overall health of the corporation – just like congressmen act as if their re-election is more important than the overall health of the nation.Continue Reading
Real World Developer Manifesto
Real World developers prefer:
- Getting things done over sitting in meetings, but understand that communication is important.
- Working code over extensive documentation, but understand that government regulations, and product sustainability require a rational approach to documentation.
- Requirements that describe business value over requirements that prescribe implementation vectors, but understand that the customer often can only express requirements in concrete examples based on his or her experience.
- Practices that work HERE over elaborate methodologies that were designed elsewhere, but understand that some established repeatable practice is beneficial.Continue Reading
Is It Me?
Occasionally – I will get into a conflict with someone, and I don’t know why. When I look back at the conversation, what I remember, it becomes apparent that either I baited someone into an argument, or vice versa.
Sometimes this happens because I attach connotative meaning to something someone says because I think I know what he or she means. Other times I have some history that comes to bear, so I project that history on top of something. In either case, the conversation becomes broken, and communication stops.
Inevitably, it turns out that I have tried to read meaning into something that someone didn’t intend, or maybe they did, but didn’t expect anyone to pick up on it, and so they are embarrassed that it was noticeable. Perhaps the best thing to do is to act as if everyone communicates superficially, and straight, and to simply communicate back at that level. To not read anything into other peoples statements and questions.
By ignoring perceived hidden agendas, ulterior motives, personal biases – my communication becomes straight; to the point. Not balled up in other peoples issues. As an analyst, I tend to try (too hard) to unwind this stuff and sometimes get wrapped around the axle in doing so. I react to my perceptions of others’ motive and agendas, rather than simply communicating facts and my opinions (when asked), I let my opinions of others interfere with communication.
Estimation Purposes
Mike Cottmeyer’s post about How to Think About Estimating is freakin’ brilliant. I applaud him for speaking his mind, and telling us how professional software delivery can get done.
Why? Because he gets down to the guts of why estimation is hard for so many teams, and while it seems to me that half of the agile community is ready to give up on estimation altogether, Mike hangs in there with a reminder that the customer has a right to a rational contemplation of cost and delivery schedule. Why – because they are paying the bill. Period. Maybe there are cases (startups, or companies with more money that sense), where the budget or the schedule are not constraining the delivery of software, where the customer doesn’t ask how much or how long. I have never been in that situation.Continue Reading