Posts Tagged ‘practice’


Wasting Time…Agile-ly

April 1, 2011

You have probably heard of Bruce Tuckman’s model describing the stages of group development – Form, Storm, Norm, and Perform.   Unfortunately many in the agile community seem to be stuck in the storm stage.  You see it in discussions that often center on positions such as: “You’re not really agile unless you are doing <insert favorite agile practice here>” or “<Insert practice being disparaged here> is not agile.  <Insert agile theory here> is agile.” or “<Insert agile solution being sold here> is the ‘right’ or ‘only’ way to do agile.” 

The latest skirmish line I have noticed is the Bottom Up vs. Top Down agile adoption arguments.  In general, the bottom up camp supports adoption starting at the team level, with adoption bubbling up, eschewing the heavy hand of corporate process improvement initiatives.  The top down camp posits that bottom up won’t produce sustainable change and that adoption must be driven from the organization level, pushing down.  (Hmmm. I wonder what Friedman and Keynes would think.) 

Why waste time entertaining such squabbles?  Stepping back to get a little perspective, clearly for any significant change to be successful you have to approach it from both the top and bottom.  The people must be educated and mentored on the new competencies.  The organization must create a structure and environment in which the people and the new changes can thrive. 

Both Dan Akerson and Matt Barcomb pragmatically discuss how to introduce agile from the bottom without ignoring the need to change the organization at the top. 

What successful approaches have you experienced (from top or bottom) that might help others improve their agility?


Simplify the UML?

November 18, 2010

I am continually amazed at the serendipity of events that occurs everyday. A short time ago I was having lunch with an industry insider when he mentioned the beginnings of a movement to simplify the UML. Having read the 700+ page UML specification a number of times (Sadistic, isn’t it?) it immediately struck me as a good idea. While software modeling is an “acknowledged” technique, it still is not a “standard” practice on most software projects. From the common, repeating questions that I have been asked over the years, many people still struggle with how to do it well. Modeling has a way to go to become truly mainstream. So a simpler UML sounded like a fine idea. But…Read More.


Come One, Come All!

June 1, 2010

If you’d like to enjoy some fun in the sun AND learn about pragmatic modeling techniques (those two things always go together, right?), then you are in luck. For the 11th year in a row, I have the privilege to be speaking at the IBM Rational Innovate 2010 conference (previously know as the Rational Software Development Conference and the Rational Users Conference).
On Wed. June 9th, 2010 I’ll be presenting “Practical Visual Modeling – Lessons From the Trenches”. Beginning and experienced modelers often wonder why modeling isn’t working well for them. This is because there are many snares and traps to fall into. This presentation, based on lessons learned from real-world projects, approaches visual modeling pragmatically. Visual modeling essentials are discussed augmented with practical, experiential advice, best practices, and heuristics for modelers. Common project failure points, SOA, agility, how to avoid typical modeling pitfalls, and simple risk-based planning techniques are just some of the topics covered.
We will discuss:
• Where the most costly and common project mistakes are made
• What parts of the UML to use and which to ignore
• Business modeling and system modeling via use cases and how to use them
• Avoiding common modeling pitfalls during analysis and design
• Project planning, prioritization, and risk
• Career shortening red flags that indicate when you should get out of Dodge.
• Numerous practical modeling techniques and practices.
So if you are going to be in the Orlando area for the conference, please drop into my session, say hello, sit back, and have some fun!


A Fool With a Tool…

February 25, 2010

So often, the development teams I coach on modeling ask “What free UML tools are out there?” As you probably know, there are quite a few now. But the problem with asking that question is these teams often have already purchased a modeling tool! Why don’t they ask earlier?

Many times the people who will be the end users of the tools are not (or just marginally) involved in tool selection. Some process or tool group is often commissioned to survey available tools, assess their applicability, and recommend what should be purchased. The tools are purchased, deployed, and then the end users find out that the tools don’t quite fit the manner in which the team actually works. This is a classic problem with a “tools first” approach to process improvement. Tools must support the way you work, not force you to work their way.

I was a member of such a tool committee at a company that was consensus driven in the extreme. We were directed to gather every possible stakeholders’ ideas on what criteria should be used to evaluate the tools. We ended up with a matrix of 123 different criteria. Did the people who would actually use the tools regularly use 123 different tool capabilities? Of course not. When the actual decision was made, after struggling through weeks of gathering, clarification and prioritization of all these decision criteria, the final decision came down to only 3 core criteria. It would have been a more pragmatic activity and much time would have been saved if we had known those 3 key criteria at the start.

But if modeling is new to your environment how would you know what you need? You may not have yet established how you are going to work with modeling. How about trying your new modeling practice with some of the open source (often free) tools? In this way you can easily and inexpensively discover what you really need in a tool for the level of modeling you intend to do. Not everyone does full Model-Driven Development. You may need only some simple diagramming capability. Maybe you won’t need that expensive gold-plated modeling tool. Every development team / organization is different. You may discover that a more modest tool may be sufficient to support your way of working.

If you want to read a nice survey of open source modeling tools read more at