Why more architectural layers = less toil (Part 1)

Thursday, November 12th, 2009 by Don Robins

In our most recent Agile Enterprise JumpStart project, we built an application and collection of web services using the ASP.NET MVC Framework for one of our clients. Our decision and recommendation to use this particular technology was based on an early JumpStart Assessment that showed (contrary to the customer’s original beliefs) that the system requirements called for both a set of web services accessible from a Flash application running ActionScript, as well as an Administrative interface for the application’s relational data. The ASP.NET MVC framework, with its capability for serving up serialized JSON or XML data, as well as HTML views directly from a controller, was a perfect fit.
Read the rest of this entry »

Hmmm, that smells nice - not a hint of a conditional in the air…

Wednesday, November 11th, 2009 by Scott Hurlbert




Agile Executive/Leadership Training Game Board Prototype Session Notes

Tuesday, November 3rd, 2009 by David Chilcott

Agile Executive/Leadership Training Session

Click on image to display full size image.

These are the notes from the second session that I gave at Agile Open Northern California 2009 exploring Agile Executive/Leadership Training. The first session was a Agile Executive Training Story workshop focused on creating training/learning stories to teach Agile to Executives/Leadership.

This session was an opportunity for us to try out the Agile Training Board prototype in a “real world” setting (ie: in front of other people).

The rationale behind these Agile Open Northern California 2009 open space sessions was to explore how to create a context where executives and people in leadership could most effectively learn about the benefits and challenges of adopting Agile principles, values and practices in their organizations.

Our target audience is an executive persona named Mike:

  • Mike is a busy Executive (SVP level) who can barely afford to invest 2 hours but wants to know more about Agile and what’s in it for him.
  • He specifically wants to know the benefits of Agile; and how he might better leverage agile practices to make better (and faster) decisions and drive profitability for his organization (in times of great change).
  • Mike needs reliable and accurate info: levers as well as costs and risks to gain a better understanding of what it will take to leverage agile for his (and his organization’s) competitive edge.
  • He is: Competitive, Smart, Impatient, Critical Thinker, Active, maybe a little ADHD (Attention-deficit hyperactivity disorder)

We started the session by introducing the game boards which where distributed around the room.
Agile Executive/Leadership Training Game Board

Click on image to display full size image.

The main Training Board was hung up on the wall as an 8′ x 5′ sticky wall. It looked something like this:
Agile Executive/Leadership Training Game Board

Click on image to display full size image.

As a team, we then posted and prioritized the collection of user stories from Thursday’s Training Story workshop (Agile Executive Training Story workshop ) into the Session Backlog as part of the session setup. This activity will likely be an integral part of an actual Agile Executive/Leadership Training Session.

I had already pre-populated the “Committed/Ready to Play” column with a number of Learning Stories including:

  • Story Title: Intro to the Agile Training Game Board

  • Story Title: Multi-tasking Impact
  • When a Learning Story was started we would move it into the “Working” column on the game board.

    So, for example, to start I moved the Intro to the Agile Training Game Board story into the “Working” column on the game board and began the intro (including tracking the time)

    After each story is completed it is moved into the “Completed/Done” column on the game board and the actual time used and the story business value are recorded on the game board

    The next highest priority story in the “Committed/Ready to Play” column was: Multi-tasking Impact - for which we did a simple multi-tasking exercise as an example of an activity based learning activity.

    When completed we moved the story card into the “Completed/Done” column on the game board and again recorded the actual time spent and the story business value on the game board

    When the timebox for the “Iteration” was done the “scores” are tallied and migrated to the Training Session Burn-Down and Accumulated Business Value Charts.

    For a typical 2 hour meeting you could reasonably expect to complete three 1/2 hour Learning Iterations.

    After completing several learning activities we stopped, due to time constraints, and we debriefed about the session and conducted a mini-retrospective.

    This is some of the feedback I received:

  • It would be useful to start the training with a set of “Practice Stories” so that participants could practice using the “TIVO remote control” process
  • It would be useful to model the entire iteration process quickly to support better understanding
  • It would be useful to have a large visual display of the remaining time in the iteration counting down
  • The story card titles need to be large enough to be read from across the room
  • It would be useful to have very clear instructions and criterion for prioritizing the learning stories
  • It was useful to see the iteration process actively modeled and integrated into the process of the meeting itself
  • It was useful to ask the group to help with timeboxing with the concensus thumb vote
  • Someone suggested that there should be three Iteration “Burn Down/Burn Up” Charts/Graphs: Value, Cost, Effort
  • It was useful to be able to read the Exercise Instructions and have a list of Required Materials on the back of the Learning Story Card
  • I’d welcome your thoughts and feedback on what you think is important for Executives and Leaders to know about Agile. Feel free to comment here or email me at David dot Chilcott AT Outformations dot com.

    I’d also like to express my appreciation to Pat Reed and her team of folks from the Gap for letting me join them and contribute to their exploration/inquiry of Agile Executive/Leadership Training. This material was an outcome of those fun, interesting and productive conversations!

    Links to Resources:

  • Agile AgileExecutiveTrainingSession.pdf
  • AgileTrainingGameBoard.pdf
  • AgileTrainingStoryCard.pdf
  • Please, oh gosh please, help the debugger…

    Thursday, September 17th, 2009 by Scott Hurlbert




    Software engineering isn’t

    Sunday, August 23rd, 2009 by Steve Bockman

    tweetthisbutton

    There’s a long tradition (since 1968, according to Wikipedia) of looking at software development as an engineering discipline.  But calling software development engineering is something like adhering to the letter of the law, rather than to the spirit.

    Software development is about acquiring knowledge

    If you think of software development as strictly an engineering discipline, you might be inclined to believe that the job of a software engineer is to apply his or her previous knowledge and training toward solving a particular problem. And you’d be right, to a point, because knowledge and training are important aspects of software development.

    But you’d also be missing the key factor, that software development is mostly about acquiring new knowledge. Software developers are always engaged in the following pursuits:

    • Discovering what to build
    • Discovering how to build it

    This goes a long way toward explaining why so much software is custom software. If software development were entirely an engineering discipline, it is conceivable that we would be able to construct just about any software application by plugging together the proper parts, chosen from a catalog of well-known, existing components. The fact that we aren’t even close to being able to do that is an indication that we still have a lot of discovery ahead.

    I’m proud to be a member of the Outformations Agile Enterprise JumpStart team, a group of developers who regularly go beyond the engineering aspects of a problem, and who constantly engage in the important discovery processes that help insure that the right product gets built.

    The Outformations Agile Enterprise JumpStart team is ready to assist you in your development efforts. We’ll take you beyond engineering, and help you discover what to build and how to build it, quickly and affordably. Visit the Outformations website to learn more about what Agile Enterprise Jumpstart can do for you.

    Avoiding the knowledge transfer bottleneck

    Tuesday, August 11th, 2009 by Steve Bockman

    tweetthisbutton
    In software development there are many ways to transfer the knowledge about how to build a product to the people who do the actual building. Production can be severely hampered, however, if that knowledge is being produced more rapidly than it can be consumed. This is the knowledge transfer bottleneck.

    I recently hosted a workshop that let participants experience three different ways of transferring knowlege in a production environment. The product, in this case, was a paper airplane of unusual design. The idea was to try different ways of transferring the knowledge about how to build the airplane from the “chief designer” (me) to the production workers, and to compare the relative productivity of the different methods, which were:
    • Documentation - The workers were given written instructions (22 steps worth) for building the airplane.
    • Reverse Engineering - The workers were given a completed airplane which they could study in order to reproduce the steps required to build it.
    • Mentoring - The “chief designer” built an airplane step by step and the workers replicated each step as it was performed.

    The experiment was conducted in two phases. In the first phase, all 8 participants used the Documentation method. In the second phase, one team of 4 tried Reverse Engineering, while the other team of 4 tried Mentoring.

    The results were interesting. Using the Documentation method, only one person out of a total of 8 came close to being able to build the airplane at all in the 5-minute period allotted.

    Using the Reverse Engineering method, 1 person out of a total of 4 produced a completed airplane in 5 minutes.

    Using the Mentoring method, each of 4 team members produced a completed airplane, and in less than the 5 minutes available.

    The knowledge transfer bottleneck in software

    In a software development effort, knowledge transfer takes place all the time, and it’s easy to imagine a software developer in the “chief designer” role described in the exercise above.

    Let’s say I’m a developer who has discovered, and written the code to implement, a technique for binding some data to the controls in a user interface, and that this technique forms a pattern that my fellow developers want to know about. If you were one of my fellow developers, would you rather I (a) gave you a document I had written about the technique, (b) told you where the code was and suggested you figure it out for yourself, or (c) paired with you to implement the pattern for a new set of data?

    Now, certainly, pairing with you takes more of my time, and might seem less efficient from my viewpoint. After all, I could be off designing the next pattern, and the one after that. But the  productivity of the team as a whole, rather than my personal productivity, is what’s important. And mentoring helps increase the team’s productivity by avoiding knowledge transfer bottlenecks.

    Outformations at Work…

    Tuesday, August 11th, 2009 by Scott Hurlbert

    tweetthisbutton

    2009 Outformations Book Project

    This slideshow catches the Outformations team and a few friends hard at work. Enjoy.

    These pictures are part of a project I’m working on to make a small photo book of our adventures. I’m just waiting on some content and I hope to publish it soon. Watch here for an announcement. — Scott

    Why should developers learn Blend?

    Sunday, August 9th, 2009 by Don Robins

    tweetthisbutton At the start of the summer, in service of my growing work with WPF and Silverlight, I decided to jump in and learn about Expression Blend in an online class at Foothill College with professor Cal Schrotenboer. Many of Cal’s classes are provided in an online format, which is great for busy developers and consultants with too little time for classroom instruction.

    As I’ve been boning up on Blend, I stumbled across an interesting BLOG entry by Josh Smith on The Importance of Learning Expression Blend where he makes a really good point that developers will need to learn Blend even if they have no intention of using it to aid in bridging the communication gap between developers and designers who will live in Blend the way developers live in Visual Studio:

    …Visual Designers think about WPF in a very different way than Developers. So different, in fact, that there is a very real potential for a communication barrier to arise between the development staff and the visual design team…it is easy to imagine working with a Visual Designer who does not have the development experience, and having trouble finding a common ground of shared concepts to discuss. The further away from “visual design” you go, the more murky the communication can become. For example, how do you discuss the proper way to create a declarative data binding with someone devoid of development experience?

    Automation concepts (see Scott Hurlbert’s BLOG entry on Form and Function) should reduce this impedance mismatch if developers have UI automated tools that morph presentation as they add controls etc., but I contend that they still will need an understanding of what they are working with to be most effective. At some point, developers and designers need to collaborate, and hence they need to be able to communicate effectively.

    My recent exploration of the Microsoft Expression Suite designers and IDE’s has exposed me to the potential of the platform, and I suspect that they will provide a level of reusability and leverage that has not been as available before with regard to the graphical aspects of LOB application development and the integration of designers and the developers working on the same project. We will be exploring exactly this intersection as we move forward with our prototyping and building out the WPF and Silverlight assests for our Agile Enterprise JumpStart in service of getting a handle on the potential productivity gains.

    Customer Feedback & Ideas Captured with Twitter-Like Interface…

    Thursday, August 6th, 2009 by Scott Hurlbert

    Below is an example which shows the  folks from GTDInbox using a service called UserVoice to collect feature request and feedback about there product.  The interface is almost Twitter-like in that messages are all very short and the interface is extremely simple.  It occurred to me that if you were to create a simple service for collecting this type of info you might be able to use it all over the place.

    GTDInbox feedback forum using UserVoice Service

    WPF in Line of Business, Why and where (by Jaime Rodriguez)…Are we learning anything?

    Wednesday, August 5th, 2009 by Scott Hurlbert