Category Archives: skunkworks

Tell me a story

Having posted about Requirement Packs the other day, I noticed this post on Brian Marick’s blog, at the time I read the PDF that he supplies with some interest, Esther Derby then linked through to Brian’s post and caused me to give it some further consideration.

During the skunkworks project that I ran before Christmas I tried to get the steering group to deliver their requirements to us in a story like manner and largely in line with the templates that I mention in my previous post. What the Steering Group ended up delivering to us were what I would consider Epics (I have started reading Mike Cohn’s book User Stories Applied: For Agile Software Development which discusses his perception of an Epic versus a Story but neglected to bring it with me on this trip.), given the time constraints the Delivery Team ended up having to take decisions during the time that they used to break the Epics down in to stories, thankfully it worked well for us and the steering group were relatively content to allow us to continue to operate in that manner.

I had a discussion with a couple of colleagues prior to my departure in which we were discussing how we approach projects. One of them stated that she thought that we should be more mindful of who the customer is when we are beginning a project and that we should consider how we engage with them to draw requirements and run the project. I agree with this and I think there are a couple of points to note.

The use of the word customer is interesting, whether it is just my perception I am not sure but I think we sometimes neglect to remember that we are a customer facing division and that business effectively justify our existance by usage. Furthermore, I think it’s important that we understand how best to engage with our customers, I would suggest that one of the issues that our customers have with us is that we go through a requirements gathering phase and then produce a large document with the requirements as we understand them at the time and then expect them to sign off on that document.

Perhaps Stories could be a useful tool on the road to overcoming both of these problems. In fact I noticed this post on Digg the other day which mentions that the Mozilla Developers and Drivers behind Firefox 3. In it they mention a Product Requirements Document which interests me further solely because of the word product. When I worked on the Skunkworks project it was very easy for me to implement an Agile approach as we were clearly delivering a product to market, the majority of the projects that we currently undertake as a division don’t necessarily view what is being delivered as a product, perhaps this is something that we also need to give consideration to to enable people to understand the Agile Concepts in books a little more.

I am aware that there are other methods such as UCD and BDD for gathering requirements, the latter of which I found an interesting post relating to how stories are used within the other day. It will be interesting to see how Dan’s document evolves but I think it gives a great explanation about the use of Stories already.

As I mentioned in the Requirements Pack post the other day, I think that each of the future Skunkworks projects should have a 2 page document outlining the perceived business value and the headline requirements for the project, I wonder now if it should take the form of a Product Requirements Document, I googled for a template and found a number of alternatives, maybe we should even consider this as a document to replace / support some of existing documentation.

When is a requirements pack not a requirements pack?

This is the second of the two work related blog posts that I spoke of, if you are here for Snowboarding related tales please feel free to visit the Red Moutain specific tag set.

I sat in a meeting towards the end of the Skunkworks project that I was working on and I was being asked about something, the subject of which I forget now, but the conversation led to how to make the projects more effective. I said that what was really needed was a 2 page document outlining the objectives of the project and what was needed to achieve them. At that point I was challenged, no, it was suggested to me that what I was talking about was actually a requirements pack. It wasn’t.

What I was talking about in that instance was a Business Justification Document, I personally think that any project, be it an internal one, relevant to a particular business area or a commercially focussed one, needs to have a sponsor, a Product Owner if you like, that is willing to say that I want to / need this piece of software because it will deliver this amount of value to my department / organistaion.

When we finally saw what was essentially the BJD (we had been calling it a proposition during the project) it focussed everyone’s minds. One thing that impressed me was that it had a bullet pointed list of 5 / 6 core features that had to be in the application before it launched, this was something that I had previously never seen in any documentation that the departments tasked with delivering IT based projects in this company had ever delivered (They had delivered requirements packs but they were long winded and some times difficult to comprehend, that is, in my opinion). These were the things that we had been waiting for, however, and this is this point that I was trying to make in the meeting and in fact now, I think each one would have been better delivered as a story. I am of the opinion that using stories help the person getting the information to engage with the Product Owner and that is why this post by Rachel Davies is interesting for that reason, Rachel, if she is who I think she is (excuse me if you are not), has been working across the road from us, furthermore, my boss has been spaeking to her about working with us (the prospect of which is exciting).

Before I left for my trip the department was on the cusp of managing a couple of projects using an Agile approach, I think some of the Project Managers are ready to see what that style of approach has to offer, it would be great to see some of the Business Analysts looking further in to this approach so as to combine our efforts, I for one think that using stories to gather requirements has a lot to offer. For anyone that is interested, I read Mike Cohn’s book, User Stories Applied: For Agile Software Development which I thought was excellent.

Well, Well, Well

This is the first of a couple of posts that I have had in my drafts waiting to be completed for a while now, I apologise if they seem a little out of context.

I came across this blog post in which the author makes a couple of points that are similar to those that I was trying to convey whilst working on the Skunkworks project before Christmas to the Steering Group and in particular, the person who was acting as the Product Owner.

I know all of this stuff shouldn’t still be bothering me, I am off work for another 9 weeks but it is. It’s important for me that the product that we were working to develop doesn’t fall flat on it’s face. Before I left it sounded though that it was going to be released to the general public and a press release made about it, having just checked the URL though it would appear that somebody has put some sort of Username / Password on it to deny access so maybe it has been sent to a limited audience. Let’s hope so.

The trouble that I think there is with releasing software that is not fully functioning is that, in my opinion, people are prepared to try any new piece of software, be it desktop or web based, I share the sentiments of the author of this post, however, that people will only continue to use software that is functioning fully. I think the rule that 80% of users only use 20% of the functionality is true and that if we as a company are to continue to develop software aimed at the commerical market we should concentrate on delivering the core feature set very well with our first bit of funding looking to then focus on the other 80%. Sadly, during the meeting that I attended with the digital steering group prior to my departure when I suggested this as an approach, I don’t think it was taken on board. Still, on my return I can perhaps continue to work moving to delivering software in that way. I think there are definitely others in the department that share my desire to see us work in this way.

Given the time constraints that we were exposed to during the project’s lifecycle one thing that we didn’t build in was scalability, we did everything that was necessary to allow to us to deliver as quickly as possible, because of the hosting environment that the organisation has and the controls that are enforced we were unable to use things like rails or django which is unfortunate as these would have obviously given us an advantage in terms of speed to deliver. Scalability will become an issue if this sofware is released to the general public without a team gaving been established to support and develop it going forward. In my opinion if the company is going to fund this going forward a Scrum team or at the very least a project team should be established to progress this piece of software in a way that those on the digital steering group would expect.

It’s interesting times for my company and my department in particular and I am dissapointed that I am not there to experience it and be part of it.

War Time Correspondence

I had an interesting conversation with somebody on Wednesday who I had highlighted my blog to. He gave me some good feedback which was encouraging.

He mentioned that my posts came across as though they weren’t really aimed at anyone which I accepted, I’ve said to a couple of people now that I see this blog as a learning aid for me, I don’t really expect many people to subscribe to the feed nor to develop a loyal following of visitors to the site, it’s just something that I can revisit at some point.

He went on to tell me about another member of staff here that had recently attended a Leadership Course that was run in conjunction with the Army. One of the Officers explained to that person that when he was stationed in Iraq he always ended the day by writing home to his wife, a, to keep her up to date of his experiences and b, to consolidate his experiences of that day to himself. This is the point I empathise with the most.

Some time ago now I spent some time in the Terratorial Army, part of my commitment was that I had to go away on Weekend Exercises. These normally meant being stationed at a Transit Camp somewhere in the country and then partaking in various exercises to form part of our training. One of the things that struck me during these weekends was just how quickly everyone slotted together as a team, particularly considering that unlike the normal Army they didn’t necessarily work together on a daily basis. Obviously the Army is very well organised, every had a job to do and they got on with it, we knew our reporting lines and were made aware of the consequences if the tasks weren’t carried out.

The Delivery Team that was assembled for this project have exhibited very similar abilities. They were all put in a room on the first day and presented with the Proposition as it stood and were allowed to feed in with their ideas, on the second day they all had some tasks to carry out which they did with minimal fuss. On the 3rd day I presented the way in which we would be working and described peoples’ responsibilities this brought the team together a little more I think and at the end of that day when we did our first planning session everyone on the team was more than willing to take on their share of the workload, even if it wasn’t what they would normally expect to be doing.

To my mind over those first 3 days the Delivery Team went from a group of individuals assembled to do a project to an effect unit of people. I’d like to say that I was directly responsible, I wasn’t. It will be important that this is replicated on a future Skunkworks style projects, may be it is just the small team ethos that facilitates this maybe not. If there is anyone out there that has any examples of how they set teams up to ensure they are effective from the outset I’d be interested to hear from you, leave a comment if you would. Continue reading

The 3 Musketeers

I’ve just seen this very interesting chapter on 37 Signals which is part of a book that has been written titled “Getting Real, Discover the smarter, faster, easier way to build a successful web based application.”, the entire book can be read online, for free here, you can also buy a pdf version here and a paperback copy here.

The reason I think it is interesting is that the article suggests that for any v1.0 software build, 3 is the Magic Number when considering team size. They suggest that the team is comprised of a Developer, a Designer and what they call a Sweeper. The delivery team on this Skunkworks project started out with 3 members (excluding myself), a Developer, a Designer and a Researcher / Analyst. We have subsequently bolstered the team with another Developer though. The Developers here typically do the integration work once the designs have been finalised and developed as HTML by the Design Team so will carry out the Sweeper role, of course, with the new toolset from Microsoft, Expression, this role may be reversed somewhat with the Designers developing UIs in the same project as the Developers in future. In the meantime and as I have previously mentioned, we’re using a combination of Axure, a prototyping tool and a command line utility written by our Developer to minimise the amount of integration work we have to do, of course, when the designs are finalised we’ll be producing the pages in the standard way.

The last paragraph in the article ties in nicely with a post that I read yesterday in which the author describes what he perceives as the 5th Agile value. He thinks the main focus of any project should be it’s desired outcome and that that is often lost sight of when the Customers are considering their desired feature set. I’ve found this to be true recently and feel that I, perhaps, was slightly to blame. I’ve been very keen to play the “let’s get a list of all the features that you require and prioritise those” and the “you can always add more” cards without truly asking whether this was absolutely essential when considering the 2 objectives that we as a Delivery Team have been set.

Interestingly, in our Analysis Session I was challenged by one of the Developers whether we had lost sight of the objectives. An interesting conversation ensued. As I stated in the post about our objectives, we’re aiming to deliver on the second objective more than the first, the problem is though that whilst the steering group here will want a feature set that gives the Wow factor (which is why I’ve been keen to play the cards mentioned above.) the Developers on the delivery team are naturally concerned that whatever code they release needs to be stable and that the way in which they have been working until now they haven’t necessarily been focussed on delivering fully tested code, let alone code that has been reviewed by a Tester. Now, I stand with a foot in both camps, I come from a Development background so I understand the desires of the Developers to release well architected and tested code, however, I also understand that from the Steering Group’s point of view and in the context of this project, which is an 8 week engagement at the end of which the intention is to have something to put before the sponsors with a view to securing further funding, the feature set must be sufficient to sell the idea. Throughout the last 4 weeks one of my favourite sayings has become “do the simple thing first”. I ended up reiterating that to the Delivery Team yesterday but also relaying to them that the understanding has always been that the first release of the application we are building may well have bugs in it, indeed, one of the sponsors commented at one point to me that he had used a couple of other applications which occupy a similar space in the market that were full of holes.

On that note, the Steering Group told me that they had reworked the Proposition document in to something a little more concrete that afternoon and so I took the opportunity to suggest that we go through the Product Backlog and move anything wasn’t absolutely essential to the delivery of this application to a list that would be highlighted in the business plan for a potential second phase should it be given the go ahead by the board.

Analyse this

I was impressed today when, having been away from the team for some time, I came back to the office where we’re currently located and found them deep in conversation around a whiteboard. Nothing noteable about that you say? Agreed. What I found impressive was that they had identified between themselves that they needed to start doing analysis for next week’s Sprint and had allocated a time (and for any future Sprints) where they would carry out that task.

This ties in very nicely with what I mentioned in my first Lessons Learned post about the Development Stream needing to be front loaded with an Analysis Stream. How analysis and Scrum fitted together had been bothering me for a little while, I’ve actually been constructing a longer post on the subject as I thought that it was worthy of a separate post. The team have chosen to do the Analysis Session on a Wednesday afternoon allowing the Analyst to then have 2 days to produce something for the Sprint Planning session at the end of the week, it also allows them Thursday morning to carry on if they need to overrun.

This means that the Analysis Stream would, in my mind, work ahead of the Development Stream (Similarly, if we had a test resource on the project I think they would work one behind the Development Stream), how far ahead is a little unclear to me though, too far and you could loose the feedback loop which I think is one of the main benefits of an Agile approach and not far enough would slow the developers down, I guess it relates to the timescales that you are operating under, 2 or 3 days suits us at the moment, on another project that may differ.

Anyway, I continue to be encouraged by the way the team have taken to the approach that we have adopted, so much so that I am going to try and introduce something else, at the planning session this week, I intend to take the work items that will be carried out and add them to a Kanban system (I’ll post a picture of ours at some point – it seems to be the done thing). I’m doing this for 2 reasons, my old boss always said that I should try and implement it and, up until now I have never found a team that I thought would take to it and secondly, we have another developer starting in the team and it will aid my tracking of who is working on what and the estimates. I’ll report back on how it works out.

Sprint 2: Lessons Learned

Following on from my post last week, here’s what I noted as lessons learned from Sprint 2.

  • Having a Proposition Up Front Will Aid the First Week of Planning (Pt. 2): I said last week that this would aid planning, I should have added requirements gathering too. I think the real lesson though is that I need to understand what the idea is and how far advanced it is. I had initially thought that if, like this project there was no clear idea / proposition that the project should be given an additional week to go through a rapid ideas generation period. On reflection though, where does that end? Will I eventually be prescribing that we put together a proposal and then go in to a design phase and then in to a develop phase and then in to testing? Frightening. The answer, well, I’m still unsure, my current thinking is that I need to consider any future projects like this thoroughly before the first week and tailor that week accordingly.
  • A Small Self Organising Team Can React To Change Quickly and Effectively: This one sounds quite obvious, and it is, to see it happen in front of you or at least to hear somebody suggest that the team switch tack completely is quite something to witness. This brings a number of other lessons yet to be learned I am sure, for example, controlling the frequency of change.

There are a couple of other things which I haven’t mentioned, I’m currently composing a couple of articles one of which I intend to post soon about Analysis and Scrum.

To be or not to be?

After our proposition was signed off on Friday the team sat down, as I mentioned and drew up a revised Product Backlog (This may not be a strictly orthodox thing to do but it seemed the right thing to do for the team.) as we did so it started to dawn on me how much work would be required of the Analyst that is working on the team.

I had a chat with her today and said that I was aware of the fact that a lot was being asked of her and that my primary concern was to make sure that she would be able to focus her efforts towards the goal of the project. I asked her to have a think about whether she could do both roles at the same time. I did this as I thought that sharing her time between the Product Owner role and Analyst role would mean that she would be spread too thin to deliver effectively on either. This is no indication of her ability at all, if anything, it is more a failure on my behalf to properly understand the tasks that she would need to undertake for the delivery team and exactly how much is involved in the role of a Product Owner.

Definitely something for my lessons learned for this week…

What a difference a day makes

Two things of note happened yesterday, firstly, in our second Show and Tell we showed the Steering Group and one of the sponsors the application thus far. We showed all the functionality that we had committed to deliver in the sprint bar forgotten password. I am so impressed with the delivery team’s accomplishments this week. The impression that I got from the Steering Group was that they were impressed too. It really focussed people on what we were doing too, I can see these Show and Tells working really well going forward as a vehicle which solicites feedback, particularly when the designer starts looking at the branding of the application for example.

Secondly, a decision has been made on the proposition. Anyone who has read any of my previous posts will realise that the fact that one hadn’t existed until now has been a concern. The delivery team got together after the Show and Tell to do the planning session for Sprint 3, one of the Steering Group joined us too. We reviewed the Product Backlog as it stood, however, it was thought that with a proposition it would be an idea to start with that and quickly note the requirements presented to us. Within half an hour we had in excess of 50 items on the Backlog all of which corresponded to functionality required to deliver the site. There were also a number of non functional requirements. This was fantastic, the team decided what functionality it was going to deliver in the next sprint, I have every confidence in their ability to be able to do that and more, we have another developer joining the team on Tuesday / Wednesday next week so it’s possible that we’ll take some more items from the Backlog and include them in the Sprint too.

By way of an introduction for the developer that will join us I intend to run another estimating session for the new items on the Backlog, as I mentioned before, we used Planning Poker which, at the time surprised me how much it served to aid everybody’s understanding of the requirement, I had played it when I did the Certified Scrum Master course and whilst I understood why it would be useful I was sceptical about how our teams would react to playing a game. I think that running that session will involve him in to the team and also get him up to speed on the task in hand.

When does an Issue become a Crisis?

There has been a known issue on this project from the outset, I have listed it in the Risk Register and monitored the Delivery Team’s perception of how much it was an issue.

Last week everyone understood that the issue, which is that we don’t have a clear understanding of who we are delivering to and furthermore of what it is that we’re delivering, was going to be the subject of discussions amongst the steering group and others that input in to that. We hoped that we would get an answer as early as possible. The answers to the above are still not forthcoming.

In yesterday’s Daily Stand Up the designer mentioned that whilst she had some work to do she would probably not be able to occupy a full day with project related work, I was not too bothered by this as the developer then went on to say that he might have need to discuss some of the prototyped screens with her.

This morning in the Daily Stand Up the designer said that she would struggle to fill her day with project related work again, the team member that we have from the business who is carrying out the analysis for us mentioned that she is starting to struggle too.

This afternoon a discussion was taking place between the developer, the designer and the analyst the essence of which was that they were all starting to struggle without this information.

I listened to the conversation and I am now meeting with the sponsor of the project to try and get some information as soon as possible. I remarked during the conversation though that I was surprised at how quickly this has moved from being an Issue to a Crisis.

Somebody then said to me, “I guess that on a project running in an 8 week timescale everything happens in condensed timeframes.”. How very true.