Better software through software architecture and devops

@jamessnape

Posts

  • Wallace McClure writes “What is the problem with Marketing People?” Where he makes the point that marketing people care more about selling product than learning about their customer’s business.

    I’m not sure this is especially a marketing affliction. In my experience they care more about “the message” that we, the vendor, wants to communicate. There is an old adage that “when you talk you are teaching whereas when you listen you are selling”. If so then their focus is probably correct. Leave the selling to the sales team.

    I do agree though that if you don’t take the time to understand your client’s business model you can end up damaging your relationship with them (and looking a bit stupid too).

    The thing to consider is the difference between commercial and business focus. The first is about sales, turnover and profit whereas the later is concerned with relationships, strategy and growth. Both are required but they need balance.

    Having had recent experience with customers wanting bespoke solutions for pocket change I’m not sure it’s always the best policy to try to get your product in by any means possible. One thought has just occurred to me - if you are a small company, is it better to lead with a product and provide professional services support or start with consultancy backed up by off the shelf product? Also, does it matter if you get the consultancy fee and don’t recommend your product because it’s not right for the situation?

    We used to have a very successful business model with the consultancy first option but have moved to a more product oriented focus. I’m not sure how it’s doing just yet. I’ll let you know.

    This entry was posted in business  and tagged #marketing  on .
    Discuss this on Twitter or LinkedIn
  • We hold these every morning at 10:30 am as it’s a time when everyone can get into the office. Three questions are asked of each developer:

    1. What did you complete since the last meeting?
    2. What blocked you since the last meeting?
    3. What do you intend to complete before the next meeting?

    The answers to these three questions give a snappy status update for the entire team. In particular, the second question is a direct request for me to do something.

    To keep the meetings short there is supposed to be no more discussion beyond the three questions. If needed then it should be scheduled directly after the meeting. However our meetings have recently begun to drag on as I found the “after meeting” gatherings weren’t happening and I let the discussion happen in-line for fear of it never happening (a self-fulfilling prophesy?).

    The side affect of this is to subject everyone to a level of detail that may not be relevant to them, wasting time and boring them. So today I’ve asked everyone to answer their questions in 2 minutes. The benefit of a short meeting is obvious but also it gives people practice at concise communication.

    Hopefully this should work, but if not then I’ll resort to a trick I used at Sony - a two-minute egg timer. Once the time runs out you have to shut up. If you have more to say then you have to e-mail everyone.

    A note for self though - I must make sure the post meetings happen.

    This entry was posted in agile  and tagged #daily-standup  on .
    Discuss this on Twitter or LinkedIn
  • Tomorrow is “Show and Tell” day. This is our take on the Scrum Sprint Review where the idea is to show the team’s progress and direction to the Chickens. The review is open to anyone who would like to come and see what the engineers have been up to for the last month. The format is fairly loose - as all the developers have laptops they can take turns to plug into a projector and show what they’ve been up to. Individual presentations are limited to 15 minutes + question time.

    The benefits are obvious: engineers get a chance to show off their work and direct feedback from the people who are dependent on their creations; Sales, marketing and management get to review progress and provide input.

    There is always a little nervousness on my part because I don’t do much speaking - it’s up to the individual developers. Their view of the world revolves around code, architecture and designs whereas the chickens think about schedules, customers and revenue. With the two positions, there is some room for difference of opinion but regular reviews keep everyone on the same page.

    So roll on the demos…

    This entry was posted in agile  and tagged #scrum #sprint-review  on .
    Discuss this on Twitter or LinkedIn
  • It’s nearly the end of the month and hence end of the current sprint. I was having a discussion with a developer this morning about the amount of work remaining on the list. The developer in question hasn’t been able to spend a lot of time on the project this month due to higher priority customer needs and therefore won’t be able to complete his agreed functionality.

    According to Scrum, we have two seemingly opposing forces:

    1. The end of sprint review where the team shows the progress for the sprint
    2. The rule that “only potentially shippable code” should be shown

    The problem is that his part of the system is the user interface and without it the sprint review will be mostly white-board and some of NUnit tests. Not very exciting and not liable to provoke much discussion. So he asked the question - “Should I just hack it to get something on-screen”? I had to think about this for a while because it’s very tempting to say yes. I could almost justify it by saying that its demo code and will be thrown away. After, musing for a couple of minutes I said no for the following reasons:

    1. Rule (2) above
    2. The sprint review is designed to show project progress and demo code is not progress
    3. The act of hacking in demo code and pulling it out again tends to add entropy and hence bugs into the system

    So a question for a future post should be “Why did I not clear the block (customer needs) for the developer?“.

    This entry was posted in agile  and tagged #scrum  on .
    Discuss this on Twitter or LinkedIn