Archive for May, 2011

User story vs use case vs “what are we trying to accomplish”

May 27, 2011 2 comments

User story vs user case …

Word documents capturing functional requirements …

Word documents – as attachments – capturing non-functional requirements …

I believe that the reason why this dialog remains very active is simple. Every framework, approach, methodology is – “a virtual construct upon reality” (not my words) that we – as humans – need as a structure to solve a particular problem.

Since every problem is unique, in almost every instance we need to find the right balance between techniques available to us.

The key in any problem definition:

– Identify interaction owners (call them actors, call them users – it does not matter)
– Identify all relevant interaction between these owners

There is absolutely nothing wrong to treat every interaction owner in any technical problem as a user and then write either Agile-centric description of the goal or Rup-centric description of the goal.

The real challenge is not writing the user story or use case in a pure format. The real challenge is to describe the problem in such a manner that it facilitates and expedites the implementation details in order to solve the problem correctly – the first time.

For example: let’s assume we are designing software which informs the pilot in the cockpit of the aircraft’s speed.

“As a speed indicator gauge, I need to be informed of correct airspeed by air speed sensor in the nose of the aircraft”.  This example clearly defines 2 interaction owners.

“As a speed indicator gauge, I need to receive information every 20 ms in a certain format”. This example defines the order of precedence and rules. The gauge has already been designed and available;  it has certain interfaces which influence data collection downstream.   We just have to honor these design elements in any subsequent interaction description.

“As an airspeed indicator, I need to measure the air pressure and convert this metric to something that speed indicator gauge understands, sent every 20 ms”. Do not know yet what the message format is.  But – engineering intent is clear.   These interaction owners have to find a way to talk to each other.

“As an airspeed indicator, I also need to inform another diagnostic device in the aircraft every 1000 ms that I am healthy and working”.  This is an example of an instrumentation requirement written as a user story.

The goal is the same: the functionality being developed must serve the consumer perfectly – as intended. The rest is simply how we get to the point of success.

Imagine if someone forgot to write the user story which captures the need to check periodically that the airspeed sensor is still working …

The results would be catastrophic regardless of adherence to any preferred process or methodology or framework.

Frame the problem correctly.  Then use all available techniques to solve it correctly.

Categories: Software Engineering

Before hiring a new manager: evaluate yourself as a manager

In any software engineering organization where the pace is usually very intense (releases, dates ….), the departure of an Engineering or Quality Engineering Manager is painful.   Sooner or later, someone very valuable with team management responsibilities will make a decision to leave.

It’s Friday PM.   You are VP of Engineering, reading a letter of resignation of a terrific engineering manager.   “G” is leaving to join a company for reasons seemingly impossible to overcome:  shorter commute, more stock options, as well as better compensation.    Thinking about the implications of this departure can spoil anyone’s weekend.

So what are the next steps?  Call every recruiter?  Not yet.

Immediately, evaluate yourself as a manager.   Regardless of the reason why someone is leaving, every departure is a reminder of the universal truth in technology organizations where great people are the key to success:  people do not leave companies, they leave managers.

Even if you are the best manager in the world, this departure will create an opportunity for you to become an even better manager.   By making the decision to complete your own self evaluation as a manager, you will be be able to retain other critical individuals in the organization.

On Monday, every attempt to retain “G” has failed.  Nothing worked.  “G” wanted to have a shorter commute and left the team in 2 weeks.

How do you look for that next perfect hire who will be able to replace “G” and become a highly respected engineering manager?

The immediate tendency is to look for another “G”.   This approach – although viable – will not answer a different question:   how do you find someone who is better than “G”?

Better “G” does not exist.   Better “G” can be developed by investing time in the new hire, by being his / her mentor.   That’s why it’ so important to perform your own self-evaluation.   Will you be willing to mentor and coach the new hire to become a better “G”?   If not – you will fail as a leader, and the new hire will probably fail as a manager.

As recruiters forward resumes to you and the recruiting process begins to produce good candidates, these candidates will most likely be in these categories:

1. Perfect manager.  Perfect technology depth.   If you can find this person  …

2. Perfect technologist.   Very good team leader.   Ready / willing to be a manager.

3. Perfect manager.  No longer willing to be a perfect technologist.

In reality, candidates in categories 2 and 3 will appear more often in the recruiting pipeline.

The candidate that shows the most potential to become a better “G” is Category 2 candidate.   But only if you are willing to invest in the new hire and coach / mentor him / her.

Great engineering managers are not hired.  They are mentored by great leaders who took the time to do what every great leader does well:   replicate excellence.

But it all starts with one’s self evaluation as a manager.

Agile vs Waterfall: how to end the debate

I have been a witness – and later a facilitator – of Agile vs every other AMF (Approach, Methodology, Framework) – for the lack of a better word.

As a facilitator, I also managed to end this debate in many organizations.

This debate should produce a clear roadmap for the team to solve a real business problem where technology plays an enabling role.   However, this very debate has been the reason why so many technology initiatives have failed.

If you are a CIO, CTO, or technology executive being placed in the position of facilitating this debate in your own organization, I hope this blog entry will help you end this debate – for a long time (or at least several budget cycles).

This may be a surprise.   The very reason why this debate exists is because – despite your every effort as a leader – you haven’t shared with your organization  what I call CTO Manifesto:

1.  “We are in the business of solving business problems, better and faster than competition”
2.  “We view technology as a competitive differentiator, and plan to be better at this than anyone else”
3.  “We care about the top and bottom line;  technology investments will have a direct & positive impact on both”
4.  “While solving business and technology problems, every technique or tool will be used or combined to achieve Goals 1, 2, and 3″

Goal 4 – unless clearly stated and explained – will lead to a counter productive debate between Agile and every other AMF (see above).

Every problem any technology organization faces on the daily basis requires a thoughtful assessment, without a predetermined bias for a specific answer which may involve application of a specific solution approach.

There is simply no substitute for a proper understanding of the problem first.

Unless the problem is properly defined – and all implications on complexity, architecture, delivery timeline, integration touch points, skills availability, organizational / training impact are at least discussed – the decision to use a certain approach as an overriding principle to solve the problem will almost always lead to a failure.    This will not be a technology failure.  This will be a failure of the technology organization to deliver  a solution which the business desperately needs to enter a new market and generate the next wave of revenue.

Many industries have ended this debate by doing what makes sense:  first – understand all  critical dimensions of the problem, then apply the right mix of tools and techniques to solve it.

Example 1:  Let’s try to build a helicopter using a pure Agile approach

– Without knowing the speed and payload requirements in advance, it’s very difficult to delay worrying about the engine and the main rotor
– Without  a proper understanding of physics (the torque generated by the main rotor), the tail rotor design will be forgotten
– The first flight without a tail rotor will be disastrous
– But:  once the need for a tail rotor is identified, several engineering team can work in parallel and quickly iterate through multiple designs
– Waterfall and Agile do exist and work well in this example

Example 2:   Let’s try to refactor a very complex software product using a pure Agile approach

– This is a perfect example, because without a proper understanding of specific goals (improve performance?  improve ease of installation?  improve error management between several components?) and how technology may have to change to achieve these goals, the effort will most certainly fail
– Improving performance is one of the most complicated software engineering goals.   It involves a deep understanding of where individual transaction are spending time in each architectural layer.
– Sometimes there is a need to write additional code just to understand where transactions are spending time
– Then, based on risks and benefits, several prototypes may be designed and engineered to learn which refactoring approach may lead to targeted objectives.  And it’s not always optimizing SQL to reduce the data access time.
– But:  once one of the prototypes becomes the blueprint for the solution, multiple iterations can be planned (some could be even be planned in parallel to save time).
– Again:   multiple techniques are required to solve this problem

There is no need for this debate.   The responsibility to end this debate starts with you.

Categories: Software Engineering