patkua@work

The intersection of technology and leadership

Page 32 of 53

Agile 2009 – Day 4

In the morning I attended the Michael Spayd’sDeep Democracy: A Radical Approach to Hearing from Every Voice” session.

What did I learn?

  • Clarity is important in a workshop format – I didn’t come away with a clear understanding about what Deep Democracy was. Perhaps it was my misunderstanding of the workshop however the program talked about the explanation and the demonstration of Deep Democracy. If they were to run it again, I would suggest being clear about what defines Deep Democracy versus not. I would avoid trying to introduce too many concepts such as relationships coaching or systems coaching unless it was relevant. Learning too many things at the same time is just plain hard.
  • Energy is important to workshops – The room was really cold and I found my fingers tingling by the end of the session (I ran to grab a cup of tea just to warm my fingers). I think an interactive workshop could have helped here, or more energy in the room. To be fair, the room was excessively large for the number of people.
  • A new acronym! ORSC (Organisation and Relationship Systems Coaching) – A certification body that teaches some coaching techniques and styles focusing on a more wholistic point of view. Whilst I’m interested in what knowledge they have to offer, I’m turned off by the certification process.

After that session I ran my session, Climbing the Dreyfus Ladder of Agile Practices.

What did I learn?

  • Assistants setting up and cleaning up make a huge difference – Thanks to Andy Palmer, Jen Mozen and Alistair Jones for your help. Having some help helped me to settle my mind both before and after.
  • Innovation happens when you state outcome (what) without prescribing method (how) – I handed out some flipchart paper and some headings and what amazed me was three different ways of putting the headings on to the flip chart given only five groups of about 6 to 9 people. What amazed me was how all of them were still very effective (one emulated what I had demonstrated, one turned the flipchart on its side (landscape mode) to fit all the headings, and another came up with a ladder based approach with items floating on either side. Wonderful, wonderful, wonderful work!
  • Using the Dreyfus Model to communicate with other coaches – I love using the model for coaching tools, yet it didn’t strike me to use it as a way of agreeing with other agile coaches, some of the behaviours that we would expect of people (although I haven’t really worked in a place where I’ve had more than myself to coach but I will definitely keep this in mind)
  • Print more compact headings – The headings I’d printed were a little bit too small to put on a flipchart in portrait mode. I’ll make more compact version so that it’s not too hard to put them as headings
  • Have bigger fonts on the slides – I wasn’t counting on being in such a large room and having the tables so far from the screen (not to mention a weird projector that stretched out the slides vertically). As such some of the slides were a little hard to see so I apologise to all the participants for that.

The only afternoon session I attended was a panel featuring my Continuous Integration luminaries, and facilitated by Tom Sulston titled, “How to be really awesome at Continuous Integration“. It was a great discussion about lots of tips for newbies to Continuous Integration and a great opportunity to ask for advice. I didn’t necessarily learn anything new yet it was nice to see some great passionate people discussing their thoughts about CI.

Agile 2009 Day 3

In the morning I attended Pascal and Portia’s The Bottleneck Game, an engaging and great place to learn about the Theory of Constraints and their use of Real Options.

What did I learn?

  • A new presentation style – Using lo-fi sticky notes on paper as slideware. Clear handwriting is a pre requisite so I think I need someone else to draw mine!
  • Inviting Observers to act as Consultants – As a way of engaging those that can’t play the game into the session
  • Portable microphones can make a huge difference – In the large room, it was sometimes hard to hear the presenters since they both had soft voices.
  • I’m not very good at folding paper hats – ^_^
  • Go slow when learning something new – The facilitators made sure we stepped through each step before moving on to the next one to ensure that we went through the motions. Too many times, it was too easy to jump over necessary stages. It was definitely helpful to be reminded to go slow when learning.

After the morning tea break, I went to Neal Ford’s presentation, titled Emergent Design & Evolutionary Architecture

What did I learn?

  • I like the distinction Neal made about design and architecture. Design is something that you can defer choices on. Architecture is something that you need before starting but can still change. It’s pretty important to make that distinction.
  • Neal has a great presentation style, very visual, combined with lots of stories. I can now personally recommend him based on my own experiences (and not just on hearsay!)
  • 90 minutes is way too long for a presentation, even if it was engaging as Neal is. I found myself fidgeting just to stretch after about 45 minutes.

Due to some longer commitments at lunch, I missed the talk Michael Feathers and Steve Freeman gave on TDD 10 years later. Fortunately I know a variation is available on InfoQ I can watch later. I had hoped to see them in person. Instead, I arrived just in time for Sharlene McKinnon’s, Iterating a Team in Flux session.

What did I learn?

  • Avatars – I really like the pictorial representation that they used for visual management. I’d like to know how they made them since they looked amazingly life-like yet cartoony.
  • Visual Management for surfacing of issues – It’s great to see how making information more visual helped them have better conversations and surfaced the problems that were already there.
  • Test your slide deck against the projector early – Sharlene had some resolution problems with the projector that could have been sorted out before the session. It was great that she didn’t depend on her slides yet could have been supported much more by the whole slide instead of the partial.

Agile 2009 Day 2

It’s at the start of the third day to Agile 2009, and I wanted to write up some notes from the conference before I start to fill my head with more ideas from the third day. It’s definitely going to be a slow start to the day, not because the program isn’t interesting, but rather since I’ve had a few hours sleep.

Yesterday was a full day and full in the sense of many wonderful things to think about. Alistair Cockburn kicked off the morning with a keynote titled, “I Come to Bury Agile, Not to Praise It“. Let’s be clear here (Cockburn emphasised this at least three times) as this will no doubt be misinterpreted by people over time: This session was not saying that agile was dead and useless. Rather, that agile has become an everyday part of life, no longer controversial and proven to be good and practical. After all, it’s been around for at least a decade now. Cockburn used the metaphor of an iceberg (agile) melting and forming part of the ocean.

If you get a chance to catch Cockburn speak, I cannot recommend him highly enough. Rather dramatically, he walked on stage following a fellow playing bag pipelines, only to perform a Shakespearen soliloquy completely memorised without notes. Very impressive! I’ll agree with some critics that I don’t think that what Cockburn had to say was controversial, yet that doesn’t automatically make it a bad thing. Cockburn articulates ideas really well, and formed a great story linking what items are essential for software development in the 21st century. On top of this is his great presentation and speaker skills, something very admirable indeed. I also appreciate his humbleness and openness to encouraging others. For example, it’s easy for someone like him to just talk about the work that he does yet he didn’t have any hesitation talking about what interesting work other people were doing, naming them explicitly on stage (something many other people in his position doesn’t do). He really knew the content in the slides, even at the end asking for to jump to content by slide number to bring up diagrams for questions. I also appreciated the fact that he didn’t jump through a generic set of slides, skipping bits that weren’t relevant and spending more time on others. That shows that he at least put thought into how the presentation was going to run for.

After the keynote, another Alistair, this time my great co-presenter, Alistair Jones and I presented our session titled, “Top ten secret weapons for performance testing in an agile environment“. Yes, looking back at it, a bit of a mouthful. We were both really happy with how it went given that the room was almost full and we had lots of questions, both during and after. Admittedly I think 45 minutes was a tight squeeze, however the program’s alternative of 90 minutes would have been far too long to talk for. Thanks to all the people that came along and we’ll be posting the content online somewhere in the near future.

At lunch, I dropped into the Programming with the stars session in the other tower, a fun place to watch different styles of how people approach and present a problem. Well done to all the participants as it takes a lot of courage to step up on stage and put yourself in front of the audience.

Later that day, I went along to the session titled, “What (Else) Can Agile Learn from Complexity?” by Jurgen Appelo that I found pretty interesting only because I’ve been reading more about complexity and chaos and how it applies to everyday life. Pretty heavy technical and term driven presentation yet very helpful for me to see how other people view it applying to software.

This session followed on with the Lean Lego Game by some colleagues, Francisco and Danilo. It’s a great experiential simulation that teaches the concepts of lean that I highly recommend everyone try. In fact, the only pitfall for their session was the fact that too many people turned up, making it difficult for two people to facilitate such a workshop.

Last night (and following through to early this morning) ThoughtWorks hosted an Agile Open Office and helped launch the Agile and PMI initiative to bring those two communities together. If you’re interested working with the PMI, they’re looking for agilistas to meet with a local PMI branch all around the world. I met some really fascinating people and far too many topics to even cover in this time.

Agile 2009 Day 1

It’s only just past midnight in Chicago however it’s like I’ve had a huge night out in London since it’s the equivalent of half six in the morning. I wanted to jot down some notes around how the first day of Agile 2009 went.

The sessions kicked off from about 11am, allowing people to pick up their registrations pack weighing about of tonne in materials including two full books (one of them admittedly a not-so-pocket sized pocket guide) and some other memorabilia. I attended two sessions throughout the day, one of them titled, Agile Grows Up: The Agile Business Analyst and then Bob Martin’s speech on the main stage about Software Craftsmanship.

Whilst I’m not sure if I came away with anything new, for me it was a nice warm up to the conference with some great discussions and, at least for me, some of the better experiences chatting in the hallways with various people from different areas. The fresher’s fair was a great idea this year. It struck me that most people seemed to identify with only a handful of communities (two to three), whilst I felt very strongly attached to many more (about ten). Perhaps it’s because I strongly believe in developing so many cross discipline skills and a focus on coaching effective teams means connecting many of these disciplines together so often.

It was great to see people that I’d met across many continents and to meet many more new people from all the way. For those that haven’t registered yet, ThoughtWorks are hosting an Agile Open Office tomorrow (pre-registrations required due to building security policies) that I hope to meet many more people tomorrow.

97 Things Every Project Manager Should Know

It looks like I have become a published author along with three other ThoughtWorks‘ colleagues (Adrian Wible, Joe Zenevitch, and Anupam Kundu) in the “97 Things Every Software Project Manager Should Know” book.

97 Things Every Project Manager Should Know

I contributed two tips, “Documents as a Means, Not an End” and “You Are Not In Control“.

You can buy it the print or ebook version of the book with a 30% discount via the Orielly.com website, using the code ABF09. Congratulations to all the other contributors to the book, including the author who organised the book, Barbee Davis.

Speaking at Agile 2009

Presenting at Agile 2009I’m excited to announce that I will be running my workshop again, Climbing the Dreyfus Ladder of Agile Practices at the Agile 2009 conference in just over a week’s time. This is the same workshop that I hosted at XP2009 in Italy. In addition to this, my great colleague Alistair Jones and I will also be co-presenting an experience report, Top ten secret weapons for performance testing in an agile environment. Hope you can make it to one of these. I’m really excited to be sharing some lessons I’ve learned along the way.

I’m keeping a page from the session here.

Agile 2009

Presenting at Agile 2009I’m running two sessions at the Agile 2009 conference.

I will be running my workshop again, titled: Climbing the Dreyfus Ladder of Agile Practices. Contrary to the printed program, Liz Keogh (who knows a lot about coaching and the Dreyfus Model) will not be co-presenting this session with me though she’ll definitely be around to chat about it. The PDFed version of the presentations is available here with a slideshow version here.

In addition to this, my great colleague Alistair Jones and I will also be co-presenting an experience report, Top ten secret weapons for performance testing in an agile environment. Hope you can make it to one of these. I’m really excited to be sharing some lessons I’ve learned along the way. A PDFed version of the slides we used can be found here, and then the slideshow equivalent here.

Alistair and I will be presenting Top ten secret weapons for performance testing in an agile environment on Tuesday in the Grand Ballroom D North at 11:00am. The other session will also be running at 11:00 but on Thursday morning in room Crystal A.

Results

The following are the pictures and transcribed sticky notes from the results of the five groups working on building up practices and classifying them according to their own thoughts. I’d promised to post them so here they are. The first results of mapping our Participating in Retrospectives can be downloaded here.

AgileEstimation

Agile Estimation

Expert

  • Lean/kanban SLA
  • Estimating at correct level of granularity based on time horizon
  • Understands limitations of estimation
  • Motivate team to be enthusiastic about estimation
  • Avoid dominance of senior person influencing estimates
  • Trusting blink! reactions
  • Adapt estimation method to tasks/group/…

Proficient

  • Shopping basket exercise
  • Uses scenarios to explore scope
  • Consider different skill levels
  • Use yesterday’s weather for hard to estimate items
  • Recognises the wise crowd
  • Use fist of five when consensus not happenning naturally
  • Discuss risks as part of estimating

Competent

  • Explores alternative strategies for solution
  • Avoids overly precise estimates
  • Identify dependencies
  • Courage to be different
  • Identify too complex
  • Including all parts of done in tasking (like TDD and refactoring)
  • Identify need for more information

Advanced Beginner

  • Using fibonnaci numbers
  • Everyone showing estimate at the same time
  • Normalise team multiple estimates
  • Creating similar sized stories
  • Avoids star trek estimation

Novice

  • Use consistent units
  • Estimate goat.com (I’m guessing via Mike Cohn style)
  • Splits up epics
TDD

Test Driven Development

Expert

  • Find good metrics to measure effectiveness of tests
  • Build patterns for testing legacy code
  • The team takes collective ownership of the test, keeping them running

Proficient

  • People understand/proficient w/the tools needed for TDD
  • The team refactors their test
  • BA’s participate in writing behavioural tests
  • Use tests to design code
  • Refactors tests -> treat as valuable assets
  • Seeking out + enabling + effective tools for TDD and CI
  • Pair programming
  • The team paris when writing TDD code
  • Revisit and rework tests as much as code
  • Write test to fit requirements religiously *before* design
  • Every team member demonstrates an appreciation for tests (no “I gotta – don’t wannah”)

Competent

  • The team has CI set up for their project
  • Openly discuss TDD w/group to bring others into fold
  • Code passes test(s) without extra functionality
  • Express intention through tests
  • The team understands the importants of taking small steps
  • Sell importance upward (e.g. done = coverage) not just demo’ed
  • Treat broken tests as backlog and prioritise

Advanced Beginner

  • The team is good at refactoring
  • People understand the value TDD brings to the team
  • Run often
  • The team keeps the tests at a unit or class level (not functional tests)
  • Confirming acceptance criteria before beginning

Novice

  • Write test
  • Run tests
  • Refactor
  • Make test pass
  • Write test cases before you code
  • No code is written before a failing test exists
WritingUserStories

Writing User Stories

Expert

  • Feature injection: Value ‘pulls’ the story creation process

Proficient

  • BA/Tester pairing on story creation
  • Use acceptance tests to drive out lower level stories

Competent

  • Create high level stories
  • Create low level stories
  • Breakdown high level to low level
  • Using user personas/roles
  • Consistent use of domain language
  • Validate storeis with target persona
  • Don’t ignore non functionals
  • Test ideas
  • Can be completed in a sprint

Advanced Beginner

  • Evolving
  • Good user roles/personas
  • Pop why stack to get to tangible benefit
  • Marketable features
  • Not too detailed
  • Acceptance criteria
  • (Uses) INVEST

Novice

  • Ask developers for size
  • Ask customer for priority
  • Use language of user
  • Follow story format template with all clauses filled
  • Create story when asked
  • Stories from user perspective
StoryWall

Story Wall/Using Big Visible Charts

Expert

  • Tell a story
  • Create chart to change behaviour
  • Recognising patterns

Proficient

  • Simplify message
  • Improving charts
  • Showing blockages/impediments prominently
  • Research alternative displays to better convey information
  • Creating new spaces to place charts
  • Making wall virtual for distributed teams
  • Remove useless charts

Competent

  • Suggest new changes – new items to track
  • Track the effectiveness of your solutions
  • Every team member updates their story when there are any changes
  • Real time updates (automated)

Advanced Beginner

  • Identify bottlenecks
  • Placing charts in a visible area
  • 1 person updates charts daily
  • Prioritising

Novice

  • Adding stories
  • Follow colour convention/standards
  • Knowhing which task to start next
ReleasePlanning

Release Planning

Expert

  • Team members produce visible release “parking lot”

Proficient

  • Plan is used as a tool to inspect and adapt
  • Stories with automatable acceptance criteria
  • Stories with consistent pointing
  • Setting expectaitons with the business around nature of overall *time* plan
  • Team intuitively understands the right level granulartiy of discussion
  • Plans account for firming sprints
  • Team members able to speak of personas
  • Using personas to help guide planning
  • Having an explicity “change bucket” ~25%

Competent

  • Have prioritised product backlog by business value/by the business owner
  • Product roadmap
  • Setting goals for the release
  • Validating overall plan with the team
  • Backlog items within consistent magnitude
  • Stories that cross all the layers
  • Identify atypical planning context – distributed – complex daomin
  • Team estimates considered in prioritisation
  • Understand team velocity
  • Including the team in arriving at planning velocoty

Advanced Beginner

  • Ability to assess relative size
  • Ability to reach team agreements
  • Stories with high variance in priority
  • Value driven and/or high risk features are scheduled early in the release
  • Plan is visible to all
  • Stories with a consistent definition of done
  • Recognise release scope will change
  • Plan is published but revisited/used at sprint closing

Novice

  • Track velocity but not adapting release plan accordingly
  • Available product owner to discuss backlog
  • Determining planning velocity
  • Have prioritised product backlog
  • Team produces release plan for Product Owner
  • Stories without a consistent definition of done
  • Stories based on infrastructure

XTC Turns 10

I’m fortunate enough to have recently started back on a project in London* this week. One of the many things that I’ve missed working in London has been access to the variety of communities that you have access to that no other city in the world (even New York City) could ever match. One of the longest running and, and without doubt most influential, on the agile community in the UK is the eXtreme Tuesday Club who celebrated their 10th year of running weekly meet ups in London.

I always find the people there great to talk to and interestingly enough this week there were significantly many more agile coaches than I’ve seen in one place for a while. I hope to be able attend these sorts of gatherings much more frequently now that I’m back in London and would highly recommend this one to any one who happens to be in town on a Tuesday.

Run automated tests as often as possible

I’ve been working with a large scale legacy system (in the Michael Feathers’ sense). Strangely enough there are a small handful of tests, unfortunately most of them falling by the way side having not been added into an Continuous Integration process. Many of them no longer look relevant, others, unable to run without a specific person’s machine (due to configuration files or special databases). Others look like a mechanism for people to simply diagnose issues with plenty of tracing statements. All of this was an inevitable system without someone running all the tests all the time.

Any serious team serious about continuous integration will think hard about their development testing strategy, considering approaches that allow you to run tests all the time. The strategy needs to consider a good way of preventing side effects from other tests (global state, global configuration, or left over state in external resources) balancing out speed with good quality feedback. Staggering build processes into smaller chunks, such as using build pipelines are a great way of achieving this.

Please don’t let leave your tests to die a sad and lonely death. It will take discipline and effort to keep them running yet the results will often pay back for themselves very quickly on any system with a reasonable lifespan.

File Associations in Notepad++

I’m a huge advocate for using Notepad++ when doing development on windows. It easily beats the default notepad.exe for being function, remains fast, and its “Find in Files” feature actually works instead of the defunct windows-search facilities.

Its menu system is a little bit different from your normal windows application, and working out how to map a specific file extension to a particular format is not exactly obvious. In this case, I wanted to tell Notepad++ to treat build files as XML files. Here’s the steps you need to go through…

Open up the Style Configurator (such a developer name!).

Menu

Pick the XML language in the left most window and under the user ext: dialogue (it sits next to the Default ext: , add build as shown in the screen capture below (click on it for a bigger picture). This will now tell Notepad++ to treat files extending with the extension build to format as XML! Viola.

Associating build files with a formatting type

Happy editing.

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders NorenUp ↑