Model Visually

I have been modeling with UML since 1995 (when I got my first copy of Rational Rose) and have had too much success with Model Visually to not include it as a best practice in my projects – especially use case modeling. Early on I used use case diagrams to augment traditional requirements specifications for OOAD. I didn’t start writing use case specifications until years later after I was given a set of use cases from hell for analysis and design. I thought, “There has to be a better way.” Well there is and Writing Effective Use Cases by Alistair Cockburn is a wonderful guide to writing excellent use cases. But excellent use case specifications take as much creativity and effort to write as it takes to design software. And… there aren’t many people who are willing and/or able to do it. I don’t mind expending the creative energy to write use case specifications; I actually enjoy it. But all that effort for something that the customer just doesn’t understand? After participating on several use case driven projects, I give up on use case specifications! There has to be a better way.

Well there is… and I am not just talking about replacing use cases with user stories. I am talking about shifting focus from molding words to molding concepts. Yes, when the team models requirements provided by (or gathered from) the Product Owner (or even if the Product Owner does it themselves) they expend creative energy but they also add immeasurable value to the development process. Since models are easy for Product Owners to undertand, the team is able to communicate understanding of the requirements while simultaneously communicating complexity of the proposed system. This has been my greatest success so far .

There is a better way… Model Visually.


Just a pinch of Salt…

I purposefully influence and teach a team so they will eventually self-organize and no longer need my services, this is what a ScrumMaster does all day. In my experience, I have found that most corporate teams take anywhere between 6 weeks to 6 months to self-organize. The more polished the team, the less time I need to spend with them. They need just a pinch of Salt… then I move on to the next challenge.

But how about if I set out to purposefully influence and teach a team that is rough around the edges like current graduates or under graduates from local colleges, or really rough like students from Mon Valley school districts that have been hit hard by recession, crime and hopelessness. Could a team like this become self-organizing? They might need more than just a pinch of Salt (probably about 12 to 18 months worth) but with excellent training and strengths-based leadership I believe these guys could become a self-organized, kick-butt Scrum team that produces high quality software pretty much on their own.

What’s the story?

Every company has a story and so does mine. It started out as Salt Consulting in August 2006 when a good friend of mine said, “Kim, you should start your own business.” Now, I can’t say that is a good reason for starting a company but the encouragement was timed perfectly. Ever since I entered the software industry in 1991 I wanted to run my own software development company yet each ensuing professional experience immersed me deeper and deeper into the awful struggle of software development. My vision slowly evolved from a desire to develop better software products into a passion to develop software products better. As Principal Consultant of Salt Consulting, I express this passion as influence and I have observed that the more influence I have the better the outcome. That is the story behind Salt Productions. This company was formed to be a software development organization that is completely influenced by Salt Consulting. I can do it better – I MUST.

Am I the only one?

No of course I am not the only one who put strengths and agile together. Jim Highsmith mentioned it in his books Agile Software Development Ecosystems and Agile Project Management and Scott Dunn’s blog Software Development and Human Capitol includes a post called Strengths of a ScrumMaster. How could the agile principle “People First; Process Second” not meet up with the strengths movement that is revolutionizing business management practices all over the world?

I am a ScrumMaster

I attended a  ScrumMaster class last week that was just plain awesome. I mean it wasn’t awesome in that I learned brand new concepts that completely blew me away. As a matter of fact, I didn’t really learn anything new except that once again I am in the right place at the right time.

As a RUP professional I confess that I pretty much ignored the Agile community… not because I didn’t think it worthy of thorough investigation but because it just never came up… not until last year when a client asked me to help them implement an Agile process for a new software development unit that was created to help meet rapid market demand. The “team” wanted to do Scrum. I didn’t know much about Scrum so I did some research, made some contacts, and learned just enough to figure out how to use the Scrum framework in the elaboration and construction phases. This didn’t make the “team” very happy but it made the PMO happy, so I considered the job done and moved on because there was no way I could make both camps happy. A less than optimal outcome, yet the experience opened up a whole new world to me.

I am a generalizing specialist and as such have marketed myself as a multi-disciplinary leader of the software development life cycle.  Sometimes I am a lead architect/designer. Sometimes I am a lead analyst. Sometimes I am a process mentor. Sometimes I am a PM. As I play my “role” in the SDLC I exert positive influence over everybody involved – the more cross-functional the better. This is why I call myself Salt. It is who I am. I am the kick in the pants that compels a team to contribute their very best.

Can you believe it? What I learned last week is that a ScrumMaster is me!