Improve with Humility

There is only one way to become better and better at what you do, and that is to learn and improve every day.

Many people in different professions will tell you that they learn every day. Others will tell you that they don't need to learn anymore. Then there are those who say they learn and learn and know so much more than others. Sometimes it is a mix.

I watch. I see the people who are good and who are what I want to be more like. They all possess one thing that truly does allow them to learn. It is humility.

The more you learn, the more you realise that you know nothing. There is so much more to learn and if we do not realise that, we can not extend ourselves.

Just be open to the fact that you do not know it all and have so far to go. That is the best lesson.

How To Operate

There is a lot more to agile than a bunch of practices that people claim they have been doing for eternity and someone has just put a name to. There is a lot more to agile than doing a Scrum course over a week and getting a certificate. There is a lot more to agile than reading a few blogs, buying a bunch of books and going to a conference.

I don't believe in big A agile. There is no one methodology for software construction. There is no one method for anything in life. There are however a whole lot of practices that when used in combination with others and in the presence of a certain level of awareness of the required patterns and undesired anti-patterns, you can run a successful agile project that results in emergent quality and software that business wants.

The one thing that I am seeing over and over recently is people coming to me and saying that they are doing agile but it isn't working. They have people on the team who have done agile before. They have people on the team who are trained Scrum Masters. They have people on the team who have bought in and want to do agile. All of these good things and yet, they are failing.

I freely use the word failing without it feeling like that is a bad thing. It isn't. Failing is a way of learning and people who can step back and say that they tried something and it didn't work, are the kind of people who learn and improve.

To actually achieve a cohesive agile environment and a team that can find their peak and attain that, you need the glue that is an agile coach or iteration manager. Some people call it the scrum master but that term is so easily obtained these days that I do not think it holds much credibility.

No matter what you call that glue, they are the person who keeps the the team moving and finds the sweet spot that is the practices and level of rigour that will work for that team in the specific environment they are in.

The famous cry of "I've been doing agile forever and they just gave it a name" is so so wrong.

You can not just grab a bunch of practices and call that agile. The famous cry of "I've been doing agile forever and they just gave it a name" is so so wrong. Agile is not just a bunch of practices and terms and things to do. It is the whole process of constant reassessment, learning, rigour, retrospective analysis and self-organisation. It is something that you must experience and learn before you try it yourself and then help others.

I always refer back to the method that surgeons use to train other surgeons to do an operation.

The method is that you "see one, do one, teach one".

See One
Participate in an agile team as a team member. Seniority does not matter. You can be an expert at anything or nothing and that doesn't change the fact that you take part in the team and learn how practices work together and how to see patterns and anti-patterns that let you choose what shapes the team.

Do One
This time, you organise the agile team and help propel it. Remove blockers; Suggest practices and tools for the context and team; Measure the quantifiable parts and communicate them; and be the glue. This can be done with the support and supervision of a person who knows how to teach or coach. They can back you up.

Teach One
Be the teacher and coach others to be members of an agile team. Let them learn about their environment and adapt to a changing environment. Your job is to enable and act as lubricant for others who are learning.



If you understand that this is the process that must happen before people are fully enabled to work in an agile way then you will understand why teams without this but with the best intentions still fail.

It also explains why having an agile expert on the team can be a peaceful process that makes the whole thing feel easy. When they leave, it sometimes feels a little unstable. They shouldn't hold all the information back or be in control. A coach should enable you and let you find your way, with a safety net.

I had a project manager say to me recently "Damana, the reason why what you do looks easy, is because it is". I smiled kindly and sadly watched him eat his words later when he took over and ran the project on to rocks.

The reason an agile coach makes it look easy is because they saw one and then did one and taught one, several times.

Too General

In the same way that we normalise and denormalise data in a relational database, we have to generalise and specify domain model design in the application.

Developers have a tendency to want to generalise things to an extreme but this often results in losing meaning. Whenever you see something called Object or Entity then it’s gone too far.

A co-worker and I had a discussion about creating a class called LookupItem to represent all reference data. There is no domain meaning in the term LookupItem. It is not a word that our business users would use so it isn’t a word we should use. If you find that commonality then let all your domain model classes inherit from a base class but still have their own class with a meaningful domain object name.

You will end up with lots of small classes but you retained a lot of meaning. Someone who walks in after you and goes to maintain the system will not have to read through the code and see what your named variables to see what a class is used for. It is in the class name.

There is also extensibility inbuilt in to this kind of structure. Often extensibility is required when there is an exception to a rule. Always build your generalisation so they can cope with exceptions to the rules.

Generalise but don’t lose meaning.

RIP Steve Jobs

He lived a life that changed the world so much that I can not imagine how it would be without him.

My first IT job was in tech support at an Apple Centre.
My first personal computer was an Apple IIC.
My first smartphone was an iPhone.
My first laptop was a Mac.

At thirteen years old, I had a huge crush on Steve Jobs and told my parents that I was going to marry him. I still held out hopes until now.

He made a difference. He made me Think Different.

A Process for creating an MVC View of Partial View

Developers were adding New MVC Views to the web application project manually and that is an anti-pattern. We want to make sure that Controllers own Actions that own Views that are bound to strongly typed view models.

This is where this process comes from. ReSharper is required in this process.

A Thousand Words

When I find myself explaining a concept over and over again to the same or different members of my team, it is a signal that I need to draw a picture.

Often, I draw the picture for a few people before it clicks that I should put it on an A3 piece of paper and stick it on a wall or take a photo and send it around in an email.

In the case above, I was explaining mapping between model classes coming out of different layers of the application. All sorts of words were being used to refer to these objects and it was getting confusing.

This image has given us an explanation of where mapping classes exist; what models coming out of different layers are called; namespaces to be used when creating or referring to mappers and models; and a common language for technical discussion.

To write that in a document would be long and cumbersome.

When you aren't explaining it in code, explain it in pictures.

The Check-In Procedure for my team

This is an email I sent out to my team yesterday. What do you do before checking in code?

---

Hello rose petals,

I’ve put a stuff to do before you check-in procedure on the wall.

In case you do not look on the wall (even though you should try to each day), here is a summary of the summary…

1. Merge all your code locally by doing a Get Latest Version from TFS;

a. Resolve any conflicts by trusting what is on the server and moving your changes in to that code. If anything can’t auto merge or conflicts seriously with your code then find the dev who wrote it and have a chat about how to make it work. This is a life skill, grasshopper.

2. Run all the tests (not just your own) and make sure they are all still working. This process is regression testing and stops you introducing a bug that causes something else with a dependency to fail;

a. Functional, Integration and Unit tests should be run.

b. If you do break something and fix it then write a test around that area because it seems fragile and may happen to someone else. Tests are security blankets. I’ve always wanted a teddy bear called CI.

3. Ensure all compiler errors and warnings are fixed;

a. Warnings exist for a reason. They speak of great tales of possible performance errors and sagas of linking and runtime optimisation. They are not there for the entertainment of the devs who wrote Visual Studio or .NET, they are for us.

b. Use ReSharper to make the little green box at the right top of each code file green. Ask me what I mean by this if you aren’t sure.

c. Use fxcop to ensure static analysis rules are complied with. Yes, even the ones you don’t love but we have decided are standard for our project.

d. Retro Steve will cry if you check in without these warnings resolved. I will look disappointed. Puppies will die.

4. Check it in!

5. Show another developer your code for review and check out the code and run the tests on their machine;

a. This means you have someone else to blame share your future bugs with.

6. Be happy. You are a good human being.

This is why I should not take pseudoephedrine during work hours. Damn cold or hayfever or something.