Thursday, June 13, 2019

When is the best time to update the scrum board?

I have worked with teams that have updated the board at stand-up and other that have updated it as they go throughout the day.  I am starting to think daily updates is an anti-pattern.

Updating the board on a daily basis turns the board from a tool the team uses to stay in sync, into a manually updated report used to tell people outside the team where you got up to yesterday.

If the business decided the priorities on the board were in the wrong order, or that some work is not longer needed... should they wait until stand-up to move the cards?

Waiting to the next day to move your card also encourages people not to pick up new work the same day another piece is completed - forcing waste into your process.

If delaying the point at which a cards gets moved doesn't have people getting confused about what to pick up next, then your cards probably don't move very often... which is also an indication each card represent too much work (and project risk).

Sometimes I get pushback that it lets the team celebrate team progress together... but if you can't ring a bell or some other signal in your work area when a story is done tor trigger a cheer... you are probably in a shared office space with other teams working on other things... and that in itself is another anti-pattern.

What do you think?

Wednesday, May 15, 2019

JsonPad for DotNet v1.3.9 is now out

For a while we have been using JsonPath at work as part of our testing pipeline, when testing JSON rest endpoints.

We use Newtonsoft's JsonPath library to perform the queries. JsonPath is not exactly a standard, and several difference exist between different implementations.

JsonPath queries that work in the online tools, would later fail in our tests causing a painful feedback loop of trial and error to get to a working JsonPath expression.

To avoid this I wrote a simple JsonPath experimenting tool using the same Newtonsoft library underneath, so when a path works in the tool it will work in the tests.

I've released this tool for everyone to use.. and called it JSONPad

I hope you find it useful too.
The latest download can be found here: JsonPad

Some Features...
* Load JSON from file or url
* Run query to display matches.
* Find in files (in Source and Result panels)
* Json folding (collapse/expand nodes)
* Syntax highlighting

Any issues? Log them here

Friday, November 23, 2018

Solution first, Product second

You can't just write a "Framework", so can you just write a "Product"?

Lots of frameworks exist that look great, until you start using them. Soon you find the model the author has in their head doesn't match the reality you are facing, and the impedance mismatch leads to confusing work around and 'cludges'.

The right approach...

Write your app. Keep concerned separated so you make a conscious decision with each piece of code "Is this part of my domain? Is this extending the language? Is this just integration code?". Build your language so your domain code is clear and expressive. (As a hint... any code that uses Generics should be extending your programming language, not your domain.)

Then when you are done... write another app that's similar. When doing this you will copy the bits that worked from the last one, and throw away the things that didn't work out.

Then you do it again!

...and again.

Eventually you have a toolkit of things that you keep copying from project to project. That's your framework. It makes design compromises in the places that don't matter to remain flexible in all the places that do matter. For each product you can use the bits you need and discard the rest.

That's why frameworks frequently come out of consulting companies. Consultants work with lots of companies solving problems in different domains, but hitting the same technical problems over and over. "Man we did this in the last project, do we really have to do it again?". Frameworks should solve these incidental problems so you can focus on the core domain.

What does this have to do with Products?

When developing a product you face the same problems. You solution may miss the point, or solve half a problem, or only work for 80% of the problem and make the rest impossible.

How do you build a product that completely solves a customer's problem? Not just work well enough that customer can be sold into buying it, but well enough that customers will go crazy for it. Gush to their friends about it. Bite your hand off if you try to take it away from them!

Feel the pain.

Pick a potential customer with a problem who is feeling enough pain that they will let you work alongside them in the hope you can help. If this customer is exemplar there should be lots of other potential customers should you provide enough value. Now embed yourself in their world until you too feel the pain.

Now solve a problem. 

Pick a problem. Start small. Quick win. Runs on the board. Low hanging fruit.  You get the point.

Then pick the next problem. Solve it. Repeat.

When you solve it.. truly solve it... don't stop until you see delight in the eyes of the user. When a problem is truly solved the pain goes away.

Sure, your customer will love you, but that's not the goal. You are building your understanding of the problems in their domain. Do this long enough and you will either solve a problem big enough that it changes how your customer works. If not, find another customer to help.

If you provide enough value, your customer will rave about you! Now point your raving advocate at as many people in their industry as you can.

Friday, March 09, 2018

Using Docker on a Remote Host: Why so hard?

I have a windows PC at work and an Ubuntu box which happens to be running dockerd.

I have the docker command installed on the windows box, but it occurred to me I should be able to run the command using the Ubuntu box as the host.

Challenge accepted.

After a bit of digging I find :
>docker -H  xxx
should work.

no luck.. fails to connect...

On Ubuntu I run
> netstat | grep docker -i
and find the 2357 port is not open... so back to google.

Turns out you need to tell dockerd to open that socket.
You can do that from the commandline when running dockerd (with the -H flag)
>dockerd -H tpc://:2357

I have no idea where the command line is being run from, so I keep digging.

Turns out you can also configure this in a config file... daemon.json

I don't need encryption as it's all on my local network.
I add in some hosts...

> sudo systemctl daemon-reload
sudo systemctl restart docker "




Turns out the commandline is also adding hosts... so you can't do both.

I decide to add mine to the command line too and remove it from the json.
> sudo vi  /lib/systemd/system/docker.service

ExecStart=/usr/bin/dockerd -H fd:// -H tcp:// -H tcp://

the didn't help... 
so I added my actual IP address... 

and that works. This isn't ideal for a few reasons. My IP address being dynamic being one.

This all took a couple of hours I won't get back, so I thought I would share.

GitHub Projects