Design & Functionality

Enterprise web applications typically favour functionality over design. Traditionally it’s functionality that wins bids particularly when the software is judged by the amount of checkboxes ticked on a tender document.

What is the cost of ignoring good design? Whilst managers may be satisfied that the chosen software can do what is needed his users may get frustrated with with time wasting user interfaces. This can make a big difference to their working lives, their health, happiness and general attitude to the organisation. The hidden cost of this moral sapping software can be vast.

Things are changing with our customers. Design seems to be making a come back. How can we satisfy the desire for design and functionality and still keep up with our competitors?

1. By getting closer to our customer we understand how our products are used and the pain points they encounter. We can spend time improving the design of these specific areas
2. By understanding our customer we understand what functionality is really needed, debunking many of our assumpotions. Reducing the time spent on redundant functionality gives us more time for good design
3. Incredible new technologies such as jquery allow us to include features such as drag and drop and speed up development of more sophisticated user interfaces

What is so great about open source software?

1. The developers who write it are passionate about solving the problem because its generally a problem for them.
2. It requires creativity to solve a problem in the limited time available. This leads to innovative design.
3. The software tends to be focused on solving one problem really well, not being all things to all men.
4. With no marketing budget the software needs to speak for itself
5. The developer is completely free to do things the right way not the quick way
6. Pier pressure keeps coding standards way higher than you would normally expect
7. It has really cool names like Git and Gimp!

Shrinking your wiki

We’ve just finished our Interim Sprint. Breaking all laws of scrum absolutely no functionality was produced but we all feel a whole lot better. Here’s what we achieved:

• Removed over 1000 stored Procedures, 300 asp pages, 21 VB Com components, 36 Database Tables and whole database from our product.
• Created a automated QA deploy
• Created a development database that we can run tests on
• Create a production installer that installs in exactly the same way as we deploy to our own machines and QA.
• Deploys now happen one way and one way only whether it’s to a Dev machine a QA machine or a customer site.
• Reduced the size of our wiki!

Its all great but reducing the size of the wiki deserves a bit more thought. I’m not sure about everyone else but our wiki is full of procedures for setting up this, deploying that or changing t’other. This is generally seen as a positive thing as it standardises work and speeds up repetitive tasks. The problem is procedures that cover every eventuality get really lengthy leaving lots of opportunities for error. Procedures that don’t cover every eventuality can cause confusion. If a task can be put in a procedure it can be automated. It takes a bit more work (possibly more work than you will ever do following the procedure) but it isn’t prone to human error. Developers are wasting their talent following procedures when they could be coming up with creative solutions.

You talk he smells

I’ve been watching Sketches of Frank Gehry. If you’ve not heard of him, Gehry is an architect who creates really radical buildings such as the titanium covered Guggenheim Museum in Bilbao above. His creative process appears to start with sketches followed by models created in cardboard that get refined and refined until he is happy. It seems similar to creating 3d prototypes in software development as opposed to 2D specifications in documents. Interestingly Gehry is renowned for his projects coming in on budget. I wonder if this is because the reality of the design  and its problems are ironed out in the prototype rather than during the building’s construction.

When asked how Gehry works with his clients a client said “You talk he smells”. I like this as an idea for a way to gather requirements. Rather than ask the product owner directly what they want (when they really don’t know) its best to just talk and “sniff” out the requirements.

A Pattern Language

Scrum has its origins in Organizational Patterns of Agile Software Development which has in turn has its origins in A Pattern Language by Christopher Alexander. A Pattern Language is full of patterns about towns, buildings and construction. In the towns section one pattern really stands out to a Scrummaster and must surely have been an influence in Scrum.

“80 Self-Governing Workshops and Offices” states “A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole. He can only understand the whole and be responsible for the whole when the work which happens in society, all of it, is undertaken by people small self-governing groups; groups small enough to give people understanding through face-to-face contact, and autonomous enough to let the workers themselves govern their own affairs” page 399.

Organizational Patterns

I wrote this in my notebook 3 weeks ago. I got home to find my wife about to go into labour. 12 hours later we had a baby girl hence I’ve been a bit busy!

I’m on my way home after some spur of the moment “There’s no bugs left lets go for a drink” drinks. Its been a good day with some great discussions. Creative juices are flowing. I’m reading Organizational Patterns of Agile Software Development. Typically of pattern books its about naming and clarifying things you may have already experienced. So I’ve been pondering the organizational and design patterns that were at work in the office today.

Breaking dependencies opens doors – Our software is too closely coupled. Breaking the dependencies takes a lot of work which may not bring immediate benefits (See “coupling decreases latency”?) but combine with “CTO feeds direction” powerful business cases can be found for the necessary re-factoring.

CTO feeds direction – Whilst out sprints focus on satisfying our customer’s immediate needs, informal chats with the CTO give us insight into the needs we could be satisfying next. Ultimately our strategy is not decided by the customer but by management. Perhaps there is a related anti-pattern, “Management overrule customers”

Superstar clears muddy waters – Our new superstar developer sees through the mud we have been wading through. After working on the same products for many years we assume many things need to be the way they are . Our new superstar sees things in different ways. This opens up opportunities for dramatic improvements to our product.

Day 18 – The Hawthorne Effect

Its the penultimate day and whilst there is still a bit more QA to do before release we are pretty much there. Next up is an interim Sprint where we get to focus on some cleaning up and automation ready for the next sprint. The Sprint Goal will be to make changes that will allow us to go faster in the next release.

I’ve been pondering the psychological effects of Scrum. I think there is a bit more to it than efficiency improvements, people seem to actually work harder. Why is that? I was originally thinking about a placebo effect. Do people actually get better just because they are working a Scrum and Scrum is known to help us work better? I raised the question on the LeanAgileScrum yahoo group. There were some interesting responses and a couple of people suggested the Hawthorne Effect was a more palausable explanation. The Hawthorne effect is described as a short term performance improvement caused by a changing environment and being observed. Since Lean/Scrum is about constantly improving our environment and being observed in daily scrums and burn down charts I think this theory could have some legs. The beauty of scrum is this improvement doesn’t seem to be short term. Perhaps it creates a self perpetuating Hawthorne effect.

Day 15 – Release First

Scrum is all about doing those things early that you normally leave till last. This avoids any nasty surprises when you should be releasing. We have had lots of focus on testing and CI but one of the really frustrating release delays for an ISV can be the building the install pack. So like testing for the next release I’m going to do the install pack first. OK so we won’t have the final code but if we automate that should only be a click or 2 away. Apart from allowing us to release more quickly what advantages does this give us? Firstly all the problems building the current install pack are fresh in my mind. While we build the next pack people will be using the current one so problems will be fresh in the users mind.  What are the downsides? Well the requirements for the install pack might change but at least we will have a solid base.

Everybody on the team seems to be buying into the need to automate more and more tasks. It still surprises me how much people have changed. I’m used to sitting in meetings desperately trying to convince people that scrum has a way to deal with our problems but these days I need to do this less and less. People seem to be naturally thinking in Scrum Terms. Whats next?

Day 12 – Freedom through trust

A day of collaboration. As we come to the release, proud of what we have achieved, the atmosphere in the office is bubbling with enthusiasm. We have a sense of freedom that comes from a real trust between development and management. Feeling freedom in the workplace is a rare thing. I’m probably going overboard we still have someone telling us what to do we just decide how to do it and even how much we do and how long we spend on process improvement.

Before Scrum I was told the best way to develop was to assign features to single developers and let them get on with it. How could anything be more efficient?! Time and time it failed, projects overrun and software became bloated. It took some convincing that there was an alternative. I negotiated short sprints as proof of concept and with each sprint confidence and trust grew.

Giving the developers full control allows us to get on with doing what we love. Writing code? No. All we want to do is become better developers. (Why else would we spend all our spare time reading books and blogs?)  Luckily for the business we measure how good we are by the quality of the software we produce.

Day 11 – It feels good

After a tough day yesterday a great day today. Managed to sign off the performance testing. Had the servers idling with 200 concurrent users, lovely. Had lunch with the CEO and talked about taking the scrum onwards, he’s a good listener and feels as optimistic about the way things are going. Feels good!