"A VALUE-UP PARADIGM"

Software Engineering with Microsoft Visual Studio Team System, Chapter 1 review:

Nothing revolutionary right out of the gate.  The authors have basically re-branded iterative and agile development practices with the term “Value-Up”.

In their re-branding efforts, they have labeled traditional waterfall methodologies as a “Work Down” approach where people don’t deliver any true value until the end of the entire project.  In contrast, the “Value-Up” approach focuses on the delivery of working/stable software early and often with continuous value added features.

Key points, snippets & thoughts:

Agile project manifesto Declaration of Independence:

• We increase return on investment by making continuous flow of value our focus.
• We deliver reliable results by engaging customers in frequent inter-actions and shared ownership.
• We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
• We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
• We boost performance through group accountability for results and shared responsibility for team effectiveness.
• We improve effectiveness and reliability through situationally specific strategies, processes, and practices.

While I think this is a good way to kick off the book, I think a reference to the original Agile Manifesto would have been a better choice:

http://agilemanifesto.org/principles.html

…  In this paradigm, you do not measure planned tasks completed as the primary indicator or progress; you count units of value delivered.  …

The focus of the entire team should be on delivering value quickly.  If you find yourself wanting to spend countless hours on things that don’t bring the customer immediate value… stop yourself, and refocus.  In great teams, people work together while focusing on the same goals and objectives.  Ideally you find yourself delivering high quality and valuable software with frequent release cycles.

Attention to Flow

Initially I didn’t like the “flow” message, but the text was fairly effective.  Software development teams benefit from having a well defined and well understood process flow for all work items.  Traditional work flow could be something as simple as the following:

• Planned
• Developed
• Tested & reviewed
• Completed

The “Attention to Flow” referenced in this book is all about understanding where the bottlenecks are.  If items begin to stack up too heavily in any one of the defined states, the team needs to refocus and break down the barriers causing the those bottlenecks.  With good process and tooling, an image like the one below (which was extracted from the book) will allow you depict workflow related bottlenecks that should lead to quick identification and resolution.

Transparency

I love that they added this to the book in the first chapter.  This section can be easily summed up with, share everything about the project to everyone, and face reality.  This book is all about the marriage of tools and process, and the key to transparency in the tooling industry is a single source of the truth (in this case, Visual Studio Team System).  If done right, transparency will also encourage shared responsibility and individual accountability.

Instrument daily activities

Most project managers that I have worked with spend nearly all of their time collecting information from multiple sources so that they can finally compile it into yet another source for final analysis, reporting, and communication.  During the design and implementation of Visual Studio Team System (VSTS), one of the goals was to instrument the process of gathering all relevant data so that people could easily correlate that data, and then present it in useful way.  Done properly, the team will be able to focus more time on adding value and making intelligent decisions.  Another goal of the VSTS team was to make this lightweight so that this could be accomplished with minimal overhead and redundancy… more to come on this topic I’m sure.

Final thoughts:

Good foundation for the rest of the book… if you’ve been exposed to agile methodologies before you won’t really find anything new in this first chapter.  If you haven’t been exposed to agile methodologies before, you probably shouldn’t be reading this blog… you have more important things to go research

The real question is, over the next eight chapters, can the authors convince me that VSTS is truly lightweight, beneficial, and worth the price?