patkua@work

The intersection of technology and leadership

Page 45 of 53

Systems Constrain Thought

March 25, 2008 / / 0 Comments

One of the most interesting observations Ajit and I made when we finished our inception a while back was that defining a system too early puts constraints around the way you work and potentially hinders learning.

We set out putting together a mental model of what we thought the system should be and what the scope of the project entailed. We did lots of brainstorming, gathered tons of input, asked lots of questions and inevitably, had fair amounts of discussion as we tried to understand it from different points of view. We tried using some software based systems like a spreadsheet, or some modelling software to capture the information we had, and eventually got too frustrated as we struggled to deal with both what we needed to model and how we were going to model it.

We found it’s much easier to work out how to model things once we understood what sort of things we needed to model. It didn’t mean we didn’t try modelling it at all. Rather, we used cheap techniques to quickly change the way we wanted to represent them. In the end, we used colour coded papers, index cards and broad categories on flip charts to represent different types of information, allowing us to group, category and reclassify bits of information quickly and easily.

Our system let us deal with larger concepts when we needed to, with the ability to drill down into enough detail to have better conversations with people closer to the project. We ended up distributing the information we modelling into more common formats – a simple spreadsheet for stories, and another for a risk log as well as some high level diagrams representing the system.

It felt much more satisfying to uncover the natural groupings of information instead of trying to cram information into the system we happened to pick.

Rituals for practice

March 15, 2008 / / 0 Comments

Ajit and I ran a mini-retrospective for one of the inception activities we just finished. We kept it simple, skipping a safety check, and running a simple two column Prouds/Sads activity. It lasted about twenty minutes and we came away with some key learnings that I know have helped at least one other person since then, making the time completely worth it.

We focused on a short brainstorming phase, noting items for both columns and skipped sticky notes all together, writing them directly on to a whiteboard wall. We then moved into a discussion phase talking about what we wrote up, noting additional ideas as we talked about them. We focused less on action items, and focused on mining tips and ideas that other people running inception activities might benefit from.

We ran it extremely informally since we’ve both used these practice many times before, and share a high degree of trust and safety. If I’d been working with someone else who I’d never worked with before, or someone who’d never participated in a retrospective, I would’ve looked much harder for an independent facilitator and suggested a little bit more structure. I think this was only possible because we’d been through the ritual many times before, and the frequent practice helped us tap into the more effective parts much more quickly.

UnFIT for use

February 26, 2008 / / 5 Comments

It always amazes me at how many people misinterpret FIT (Framework for Integrated Testing) and I guess it’s based on the way that it’s been marketed. I’m not exactly a big fan of FIT and the biggest reason is that people don’t really understand what it’s best for, and use it all over the place where it’s not very appropriate more so than people who do know what they’re doing with it. In the last month, I’d heard statements such as “FIT is good for driving tests below the UI layer”, “FIT is great for acceptance tests”, or “We use FIT all the time”. Please stop this!

Let’s have a look at this table I put together that compares FIT and JUnit. Of course, this comparison also applies when comparing FIT to NUnit or one of its other close brethren (TestNG, etc):

JUnit Comparison Versus FIT (Framework for Integrated Testing)

Let’s get this straight: The only thing FIT is good for, is using it as a tool to help communicate with a customer. That’s it. It’s terrible for writing automated test suites, FIT encourages terrible programming habits, IDEs offer very minimal tool support and many developers don’t seem to really understand, nor want to understand how it works. I’ve seen a test suite where developers deployed FIT tests to a web container because “it was HTML” and they thought it had to be deployed for it to run. Grrrr.

The biggest barrier for FIT is that it requires a lot of education around how developers best use it, how they use it to help aid communication, and then understanding how to maintain it. Unfortunately I’ve never seen the payback you get from investing this time that’s better spent directly trying to improve the communication gap. I think it’s because the conventions used to bridge HTML to code aren’t natural and, without spending the effort to really help developers understand it, quickly leading to a whole mess of tightly coupled code and eventually, test coma.

The recommendation
I’d use FIT sporadically to help bridge gaps between the team (analysts, developers, testers) and the customer – especially for data driven examples. Acceptance level tests in JUnit should be refactored to a point where it’s understandable to customers (i.e. using as much of their language as possible). If you decide to go down the FIT route, refactor mercilessly to split out what the FIT fixture do and how they do that (some sort of driver, component, etc). In my experience, the latter should be immediately usable in another test framework, and in fact, should be what you’re striving to reuse in that other test framework.

BCS Talk: Agile Programme Management

February 25, 2008 / / 0 Comments

Last Thursday I went along to a BCS (British Computer Society) organised event presented by a major influence in the DSDM space, Jennifer Stapleton. Thanks to Ian for recommending this as I really enjoyed her talk.

The Presenter
As a presenter, Stapleton obviously knows what she is talking about. She’s extremely comfortable with the content, and extremely lively on her feet – something I’m not sure the level-floored room was most ideal for. I’ll admit that her slides appear a little old fashioned with lots of bullet point text, or just lots of text and, what looks like, clip art all over the place. I do think, however, that the content is definitely worth while. The lessons she’s learned from her eleven (plus) year involvement with DSDM, considered as one of the earliest agile methodologies, certainly shines through in many of her examples.

The Audience
The event apparently sold out the week the BCS announced it and based on the names on the empty sign up sheet and the number of empty chairs, I guess a lot of people didn’t turn up. A few people who turned up on the night didn’t seem to have any problems entering. I noticed many more people with grey hair and suits compared to the other events I’ve been to (mainly agile gatherings, or language specific interest groups). Based on the questions thrown from the audience, I guessed a higher proportion of them worked for government agencies and a few of them came from academic backgrounds.

The Content
I think that what Stapleton had to say was extremely compelling, though if you’ve done agile software development, prepare yourself for a different world. Programme management goes well beyond what you’d normally think about, especially at the project level, and although applying agile principles at that level probably isn’t different, I’m sure the practices that go along with it are.

She started off by clarifying some of the terms that she used – the differences between a programme and a project, the differences between a programme and a portfolio and how she describes tranches (think iterations at a bigger level). I think her definitions of the terms are essential as I think a lot of people simply group things together and label things incorrectly as a “programme”.

She talked about what you need to be an effective programme manager and how you go about managing portfolios, programmes and projects to meet a programme. She talked about the impact of budgeting cycles that last a year, and the impact it has (feast or famine), finishing with her “Agile Programme Management Maturity Model” (yes, another one!), a tool that helps her evaluate organisations she works with. She also touched very briefly on feedback and cycles of feedback needed although I don’t think she emphasised it nearly enough.

Find her slides at the London Central BCS website.

A few new terms
SRO – Senior Responsible Owner – The SRO should also work out if the structure required to deliver the Programme can realistically be achieved, in order to confirm that policy can be delivered.
MSP2007 – Managing Successful Programmes 2007 – A qualification around the programme management space.

The Takeaways

  • I like the fact that she explicitly considers change projects that tend to either flow alongside or follow a project (which also, may or may not be software based). In my experience, sponsors rarely think about how their project impacts other people and their roles in the organisation and this often has a huge impact on their success.
  • Agile organisations need agile leaders. According to Stapleton and in response to my question, they’re not somebody that you can train (although I’m not convinced about that if you consider mentoring).
  • At the programme management level, you don’t need to worry about the agile development process – instead it’s a focus on setting the right metrics (aligning rewards with goals and outcomes), and understanding how to co-ordinate and communicate results.
  • DSDM explicitly addresses a fixed vision problem not necessarily solved by XP or Scrum directly.
  • Simply presenting a model is not enough – I can see how people in the early stages of learning about agile programme management might use the APMMM as a direct measure (e.g. Organisation Z fits in category X because they do this or that) instead of trying to work out how to use it as a way to measure progress, or direct change.
  • What Stapleton talked about covers a lot of principles. A gap of practices still exist that make it difficult for inexperienced people to apply directly. It’s all good to want to get to X, the question is, what’s the best known ways of getting there or, at least, what are the options?

Losing my London .Net Users Group virginity

February 20, 2008 / / 1 Comment

About 60 people (only of which three or four were female) crammed into a tiny room near Red Lion Square last night for the London DotNet Users Group meeting. I have no idea what the normal turnout rate is, though I guess the topic (TDD) probably drew quite a lot of people. Three people presented and the meeting ran for a total of three hours until 9:30pm at which point, we left for the pub and stayed until closing.

The three presenters for the evening and the topics included:

  • Zi Makki: TDD and the Data Access Layer
  • Sebastien Lambla: The MVP pattern
  • Ian Cooper: Best Practices for TDD

The first presenter covered some techniques for dealing with integration points with a database. I noticed that he used Coderush (all those bright colours and arrows hurts my eyes!) instead of Resharper though I think he was using VS2008. It seems that Coderush also lacks a way of extracting a class into a file for a different assembly or at least it wasn’t used. I’m pleased the presenter used BDD styled should as I’ve found these help focus the person writing the test. He finished with some very useful tips though I was worried by one of his final statements, “Avoid Integration Tests”. I think as a principle, fine. For someone in the early stages of learning TDD (think of the Shu in the Shu Ha Ri), it’s a dangerous blanket statement they may follow as integration tests can be useful points of feedback as well.

The second presenter talked about the Model View Presenter Pattern although after seeing his implementation, and I think it is probably more an example of both the Supervising Controller and the Presentation Model. I find it interesting to see how far Sebastien pushed the databinding features of ASP.Net. It’s given me some thought about how I might actually give databinding another real chance. I’m really interested to see how this works in an update mode in this same world. I also learned here that the Macbook Air isn’t great for doing presentations where you need to write code (the buttons are too small!)

The final presenter, Ian Cooper talked over lots of best practices around Test Driven Development. Ian has plenty of great things to say and one of my only issues was that there was probably far too much content on the slides to cover in just an hour.

One of the other topics that wasn’t covered and I think is important for newbies to TDD is understanding when to or when not to use it. As I wrote in a previous post, if you’re doing TDD all the time, you’re doing something wrong.

I really enjoyed talking to other people who went along and I’ll definitely be back again sometime.

The Extended Agile Reading List

February 20, 2008 / / 1 Comment

Update (20 Feb): I probably want to add the same disclaimer that I did on the previous post. I highly recommend doing reading on these things and I do want to emphasis that reading will only get you so far, so try to find someone who’s worked with in this way before (i.e. an agile coach) to help you apply all these concepts appropriately.

Building upon the Essential Agile Reading List, here’s the extended one that includes either books that I’ve not read (and have been recommended) or those that help facilitate further understanding or more advanced practices.

Methodologies and principles

Additional context

Teamwork

Continuous Improvement

Project Management

Requirements and planning

Development practices

Some notes on C# 3.0

February 18, 2008 / / 3 Comments

I’ve been playing around with some of the new features of C#3.0. I installed VS2008 and the new Resharper 4.0 EAP available here. I expect most of the Jetbrains EAP stuff to be pretty buggy and I’ve already had it crash on me more than five times today. Still, being able to refactor and navigate around files is worth the buggy trial.

Out of the box support for the new language features looks interesting as well as some of the new tools and refactorings in place. Interestingly, default settings suggests constant use of the new var keyword replacing the class declaration you should be using. I’m a little uncomfortable with this as the default setting though it could be because I’m not used to seeing C# code like that.

I started playing around with extension methods, trying to convert the ReflectUtil I wrote back in this post. After a rewrite, some of the APIs looked a bit better although at the cost of making some private inner classes and delegates public. I’m not sure if I like it yet and still trying to think of some guidelines for when to use it. I think definitely having all the extension methods grouped together would help – either in one big Extension class (if you don’t have too many) or in a [Class]Extension class so they’re much easier to locate. If you find youreself writing StringUtil classes, consider converting them to Extension classes. Right now, extension methods only work on instances, so if you want to be able to add static methods, vote on the topic here. I’m not yet convinced it’s that useful just yet though.

Lambda expressions look especially nice although now it’s just plain confusing how you have three ways to do something and there’s really little benefit out of the two more verbose ways. Use this to replace anonymous delegates with a less verbose method.

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders Noren — Up ↑