Skip to content

Feed aggregator

VersionOne Announces SAFe 3.0 Alignment

Agile Product Owner - Sat, 10/11/2014 - 14:11

VersionOne just announced their latest update in support of SAFe 3.0. See here for details.

Categories: Blogs

Lessons from running Neo4j based ‘hackathons’

Mark Needham - Sat, 10/11/2014 - 12:52

Over the last 6 months my colleagues and I have been running hands on Neo4j based sessions every few weeks and I was recently asked if I could write up the lessons we’ve learned.

So in no particular order here are some of the things that we’ve learnt:

Have a plan but don’t stick to it rigidly

Something we learnt early on is that it’s helpful to have a rough plan of how you’re going to spend the session otherwise it can feel quite chaotic for attendees.

We show people that plan at the beginning of the session so that they know what to expect and can plan their time accordingly if the second part doesn’t interest them as much.

Having said that, we’ve often gone off on a tangent and since people have been very interested in that we’ve just gone with it.

This sometimes means that you don’t cover everything you had in mind but the main thing is that people enjoy themselves so it’s nothing to worry about.

Prepare for people to be unprepared

We try to set expectations in advanced of the sessions with respect to what people should prepare or have installed on their machines but despite that you’ll have people in varying levels of readiness.

Having noticed this trend over a few months we now allot time in the schedule for getting people up and running and if we’re really struggling then we’ll ask people to pair with each other.

There will also be experience level differences so we always factor in some time to go over the basics for those who are new. We also encourage experienced people to help the others out – after all you only really know if you know something when you try to teach someone else!

Don’t try to do too much

Our first ‘hackathon’-esque event involved an attempt to build a Java application based on a British Library dataset.

I thought we’d be able to model the data set, import it and then wire up some queries to an application in a few hours.

This proved to be ever so slightly ambitious!

It took much longer than anticipated to do those first two steps and we didn’t get to build any of the application – teaching people how to model in a graph is probably a session in its own right.

Show the end state

Feedback we got from attendees to the first few versions was that they’d like to see what the end state should have looked like if they’d completed everything.

In our Clojure Hackathon Rohit got the furthest so we shared his code with everyone afterwards.

An even better approach is to have the final solution ready in advance and have it checked in on a different branch that you can point people at afterwards.

Show the intermediate states

Another thing we noticed was that if people got behind in the first part of the session then they’d never be able to catch up.

Nigel therefore came up with the idea of snapshotting intermediate states so that people could reset themselves after each part of the session. This is something that the Polymer tutorial does as well.

We worked out that we have two solid one hour slots before people start getting distracted by their journey home so we came up with two distinct types of tasks for people to do and then created a branch with the solution at the end of those tasks.

No doubt there will be more lessons to come as we run more sessions but this is where we are at the moment. If you fancy joining in our next session is Java based in a couple of weeks time.

Finally, if you want to see a really slick hands on meetup then you’ll want to head over to the London Clojure DojoBruce Durling has even written up some tips on how you run one yourself.

Categories: Blogs

Ripping the Planning Out of Agile

Agile Tools - Sat, 10/11/2014 - 08:22

needle-31827_640

Recently I was following some twitter feed about #NoEstimates. I’m no expert, but it seems to be a conversation about the fundamental value, or lack of value, that planning provides to teams. What they seem to be arguing is that planning represents a lot of wasted effort that would be better spent elsewhere.

Fundamentally I would have to agree. I’ve wasted a tremendous amount of time arguing about story points, burning down hours, and calculating person days – all for what seems like very little benefit.

What I would rather do is spend more time talking about the problem we are trying to solve. I really value a deep understanding of the system and the changes that we intend to make to it. If I have that much, then I’m well situated to deliver fast enough that nobody’s going to give me much grief about not having estimates. That’s my theory anyway. The sooner you can deliver working software, the sooner people will shut up about estimates.

But often we never do talk about the problem at anything other than a very superficial level. We spend most of our time trying to size the effort according to some artificial schema that has nothing to do with the work or any real empirical evidence at all.

So what if there were no plan? What if we took Scrum and did everything but the planning? You show up Monday morning and you have no idea what you are going to work on. The team sits down with the customer and talks about their most pressing need. They work out what they need to build, make important design decisions, and coordinate among themselves. At no point are there any hours, or points, or days. What would happen to the cadence of the sprint if we removed the planning? Basically, we would have our daily standup, and then we would review our accomplishments at the end of the sprint and look for ways to improve.

That sounds pretty good actually. Like anything else, I’m sure it has pros and cons:

Pros: Save time and energy otherwise wasted on estimation, and use that time instead for important problem solving work.

Cons: Stakeholders really like estimates. It’s like crack. They start to shake and twitch if you take their estimates away. Not many will even let you talk about it.

It might be worth a try sometime. It would certainly make an interesting experiment for a sprint or two. What if the sprint were focused entirely on the improvement cycle instead?


Filed under: Agile, Scrum Tagged: #noestimates, Agile, estimates, Planning, sizing
Categories: Blogs

I am an ironing board

Business Craftsmanship - Tobias Mayer - Fri, 10/10/2014 - 17:46

Session Notes for Open Space session at Agile Open, California, Thursday 9th October 2014. Around 25-30 people in attendance.

image

Session title: Metaphor—Why?

Introduction: (System) metaphor is one of the original XP principles, but has been neglected over time in favor of other, more actionable principles such as test-driven development and continuous integration. A system metaphor creates a shared understanding, and its absence often creates misunderstanding and misalignment. In this session I’m interested in exploring metaphor, not specifically for code, but for human systems,and also individuals. Metaphor can create new understanding, new ways of looking at familiar situations. What might it mean, for example, to say to someone, “you are an ironing board”.

Part #1

For want of a plan of any kind, I started the session with this question, and asked participants to pair up and explore what it meant to them. Some pairs explored it from a personal perspective, and some from the perspective of their work role, e.g. developer or Agile coach. In sharing we focused on “I” statements, and paraphrasing…

"When I am folded away in a closet I see the world differently to when I am out in the open, being of service."

"I seek something hot and steamy to be pressed against me."

"I am the body of workers that supports the change agent (the iron) in removing the wrinkles in my organization (the clothing). Without me there is no foundation for improvement"

A nice corollary for this last one, from the iron’s perspective, was “If I stay too long I will burn a hole, and ruin what I am trying to improve.”

The neat thing about facilitating an open space session, is the sense of release. The session goes where it goes, and all I needed to do was embrace the ideas that emerged, turn them into offers, and suggest some containment for the dialog.

Part #2

The “I am” statement led a participant to be reminded of an improv exercise called Invocation, where an object is identified of spoken of in four different ways, each one taking the speaker from objectivity to subjectivity: “It is…”, “You are…”, “Thou art…” and “I am…” We practiced this framework in the second part, people finding a new partner and offering an object of their own choice, e.g. bird, flipchart marker, redwood tree, highway… The use of this framework led people to greater empathy. Was that what we were seeking with metaphor? Perhaps. The following discussion looked at the difference between the incremental understanding and the immediate jump to “I am”. The latter is more of an analogy: I am like this thing because… opening up new ways of seeing self, while the former takes the speaker deeper into a place of understanding of the other (thing). 

Note: when my partner struggled with the “Thou art” part, I asked him to recite a love sonnet to the flipchart marker he was holding. “Thou art an extension of my imagination…”, he began. I don’t recall the rest but it was very eloquent, and oddly moving. When he tried to do the same in front of the group he wasn’t able to, and afterwards commented how wrong it felt to express intimacy in front of a large group.

Part #3

We discussed the idea of using another person as the “object”. A traffic cop. 1) It is an authority figure, uniformed, unwelcome. 2) You are a man with a job to do. You need to earn a living like the rest of us. 3) Thou art a keeper of the law, a man with a mission. Thou art possibly a family man, seeking to improve the life of your family in the best way you can. Thou enforces the law because thou believeth in justice.” 4) I am a man with a mission, a believer in truth and justice. I care for my community and want to help others do the same. This had now moved beyond metaphor into a pure empathy exercise. Time for a retrospective. Are we getting what we want from this session? Where do we want to go now?

Retrospective

I asked for the five most vocal people to form small teams. Their job was to facilitate a dialog and not speak themselves. One of them asked, what, not speak at all? I had rather meant that they did not offer input but made sure all voices were heard, but this was an idea worth exploring. Yes, facilitate in complete silence. Feedback from the facilitators was interesting. In general it improved the ability to listen. The retrospective gave us three topics to explore further, so we created an short open-space-within-open-space. 

Part #4

  1. The use of metaphor in retrospectives—how would it help to ask participants to come up with a metaphor for the last sprint? What new avenues of exploration/understanding might it encourage?
  2. Exploring common metaphors, e.g. herding cats, war room, firefighting. Many of our metaphors are negative, or derogatory, creating a (perhaps) undesirable mindset. We looked for new metaphors, and the one that shone for me was a new way at looking at “cat herder” (a typical description of a project manager). I am a builder of playgrounds. This idea completely changes how one might approach their job: don’t try to manage the chaos, embrace it and support it with fresh imagination.
  3. Empathy via Invocation. Some wanted to explore this further. I have no notes for this short session.

Time expired, so the small groups dissolved. I asked those remaining at the end to practice with each other during the event, by simply offering a “you are an [object]” challenge to one another at random moments, and see what happened. As I left the eception at the end of the day, I offered a colleague “You are a stuffed mushroom”. I look forward to hearing what he had to say to the others in the group when we next meet.

Categories: Blogs

New daily stand up questions

Xebia Blog - Fri, 10/10/2014 - 16:51

This post provides some alternate standup questions to let your standup be: aimed forward, goal focused, team focused.

The questions are:

  1. What have I achieved since our last SUM?
  2. What is my goal for today?
  3. What things keep me from reaching my goal?
  4. What is our team goal for the end of our sprint day?

The daily stand up runs on a few standard questions. The traditional questions are:

  • What did I accomplish yesterday?
  • What will I be doing today?
  • What obstacles are impeding my progress?

A couple of effects I see when using the above list are:

  • A lot of emphasis is placed on past activities rather than getting the most out of the day at hand.
  • Team members tell what they will be busy with, but not what they aim to complete.
  • Impediments are not related to daily goals.
  • There is no summary for the team relating to the sprint goal.

If you are experiencing the same issues you could try the alternate questions. They worked for me, but any feedback is appreciated of course. Are you using other questions? Let me know your experience. You could use the PDF below to print out the questions for your scrum board.

STAND_EN

STAND_EN

 

Categories: Companies

Codea Calculator

xProgramming.com - Fri, 10/10/2014 - 16:30
Codea Calculator Warning

This is long. Bring food and water, or read it in parts.

Be aware of this, please: with all these words, all this explanation, the project itself goes very smoothly. My suggestion is that it wasn’t all these words, but it was the attention to testing, simple code, incremental development, and keeping the code clean.

See what you think!

Initial Thinking

Codea is a lovely Lua development system that runs on the iPad. I enjoy building things with it. Recently, on the forums at codea.io, “dave1707″ posted an example of a little calculator, as an example to some new member. I thought I might put together a description of how I might do a similar thing.

I expect to find a lot of differences between Dave’s calculator and mine, so I’ll keep my functionality the same as his. Predicting what will come out, I expect that Dave’s version will be many fewer lines of code. It will probably be more “efficient”, though it’s not clear just what efficiency means in a program that spends its time waiting for someone to press a button. Anyway, we’ll see what happens, and in the end, everyone gets to do it the way they see fit.

I did read Dave’s version and sort of figured out what it did. That might influence what I do now, but we’re always building on everything we know. It may also have confused me, especially since I didn’t type it in and run it. We’ll see if we see his influence on this version, or not. I’m happy either way.

There will be a lot of words here, because I’ll try to put down all my thinking. My experience is that it takes more than twice as long to write an article like this as it does to write the program. That’s because we all think a lot faster than we type. At least I hope so …

Calculator Operation

I started by drawing a little sketch of how this kind of calculator works.

calc

My “theory of calculator operation” is that you have buttons, a display, and a temp register. The buttons come in digits, standard binary infix operators (+ – * / ^) and sin/cos, which are a different kind of operator, as we’ll see. These are unary operators if you’re into terminology.

When you press a digit key, that digit appends to the digits already in the display.

When you press an infix operator, the operation implied is performed between the display register and the temp register. The result goes to temp, and the display is cleared. When you press a unary key, the operation is immediately applied to the display and the result left in the display.

Now I’m pretty sure this is how calculators are supposed to work. It’s possible, though, that I just don’t get it. So I’d like to find out ASAP whether this design will work.

Program Design

Well, there will be buttons. I plan to rip off Dave’s design for the buttons, although I expect I’ll generate them a bit differently. We’ll see what we need.

And I plan to build a calculator object, in a class. Dave put his functionality right in the buttons, which certainly works fine. My training and experience lead me to put separate function into separate modules, in this case, objects. If I were just whacking out a calculator, I might do it differently. I might even build something along Dave’s lines and then refactor it to a design that I like better. (Of course I might just leave it alone, if it was working fine, especially if it was just something I did for fun.) But for today, I’m going to break out the calculator as a separate class. My plan is to test it as I go.

First Implementation Begin with a test

As usual, I start with a test. I’m putting it in setup, and the initial cut looks like this:

c = Calculator()
c.press("1")
c.press("3")
c.press("*")
c.press("3")
c.press("=")

So I’m assuming I’ll have a Calculator class, and that it understands a press method. I’ve not checked any results yet but I expect to see display containing, in order, 1, 13, nothing, 3, 36, while temp will contain 0 (or nothing), 0, 13 …

WOW, wait! My design is wrong! I’m thinking that when you type the ‘*’ it will apply the operator multiply to temp and put the result into temp. But the temp at this point will be zero, so that won’t do. It would zero the result.

I am tempted at this moment to read Dave’s version and see what it does. But we won’t always have Dave to rely on so I’m going back to the drawing board to figure out how these things work.

… thinking and sketching ensues …

OK, I have a new theory of operation. The calculator has to remember the operator you type, and when you type a new operator, then it applies the old one. And then it remembers the new one.

I’m still thinking I can work with just one temp register but I’m uncertain.

There are a number of things one can do when uncertain. One of them is to think more. The other is to have the computer help you, by programming something to see what the program really wants to be. In the past, I used to design for a long time. My more modern practice is to do my design thinking, as much as possible, with the program there in front of me. So I’m going to extend my test to examine some results and then I’m going to code a Calculator.

Revised test
c = Calculator()
c.press("1")
c:displayIs("1")
c.press("3")
c:displayIs("12")
c.press("*")
c:displayIs("12")
c.press("3")
c:displayIs("3")
c.press("=")
c:displayIs("36")

Now, of course, I could just print the display after each step. And if I weren’t trying to demonstrate a sort of “test-driven” approach, I might. After all, it’s just a calculator. What I’m doing here, though, is different from testing by printing in a couple of ways.

First of all, I’m saying right in the code what I expect to happen. So I have designed and specified the behavior of the calculator, right here in plain sight.

Second, I’m setting up a test that I can repeat without looking at the printout and checking it by eye. In this case, it may not be worth it. Even here, it might be. In a larger program, that grows and changes for a longer time, this kind of test can be quite valuable in assuring me that I haven’t broken anything. Because I surely will break something.

Now to write a calculator that can do this. I’m not sure what the displayIs function will do just yet but I’m thinking it’ll print the display and say whether it’s happy. It might do nothing unless it’s not happy. We’ll see what we like.

First Version — just shows errors

Here’s what I did:

Calculator = class()

function Calculator:init()
   self.display = ""
end

function Calculator:press(key)

end

function Calculator:displayIs(string)
   if self.display ~= string then
       print("expected", string, "but got", self.display, "!")
   end
end

I decided that I don’t want the displayIs whining at me all the time, so it’ll just print the exceptions. Of course right now, it gets everything wrong so all the displayIs calls print an error. I hope to fix that soon.

Next Version — eliminate an error or two

So, OK. Next step is when a digit is pressed, append it to the display string. At least that’s my plan. Here goes:

function Calculator:press(key)
    self.display = self.display..key
end

Now you may find this interesting. All I’m doing is appending every keypressed to the display. This is clearly wrong! Why would I do such a stupid thing? Well, my story is that it’s simple, not stupid, and I’m sticking to it. This “implementation” makes my first two tests run, and the rest still fail. So it is progress. I prefer to write as little code as possible between a test failing and success.

A concern people often raise about working this way is that I’ll have to change a lot of code. We’ll see. What usually happens is that I add code, but don’t often have to replace or change much.

Mind you, I don’t always take such tiny bites. It’s easy to get on a roll and slam in a lot of code. Then, inevitably, I have to debug it. I don’t like that: I’d rather have a program that works a bit, then a bit more, then a bit more. Your mileage may vary. I’m showing a particular way of working here. Take what you wish from it, ignore the rest.

Make it clear on star

Now I need to make another test run, the one where you type * and I expect the display to go from 12 to blank. Tell you what: I’ll just code this much: “When the star is pressed, clear the display.” That will give an interesting outcome I think.

function Calculator:press(key)
   if key == "*" then
       self.display = ""
   else
       self.display = self.display..key
   end
end

The tests fail! Look at these lines:

c.press("3")
c:displayIs("12")
c.press("*")
c:displayIs("12")
c.press("3")
c:displayIs("3")

OK, well, that was just dumb. My calculator is supposed to do nothing on star, and then when you type another digit, it should clear.

Did you see that that was going to fail? Are you thinking “how dumb”? Well, I took a break for lunch between the last test and this one, and I forgot what the test was. I just coded what I thought it was. I should have looked but I started typing before I got my iPad out of the bag.

Oddly, this doesn’t bother me, because my tests immediately tell me “how dumb”. That’s why I like having them: they remind me of what I was doing when I come back from lunch. What people who work this way will often do, before they leave for the day, is write one new test that fails. The failing test reminds them what to do when they come back.

If this all seems odd to you, I’m not surprised. It was odd to me when I started working this way, oh, 15 years ago. And I’ve shown a lot of other people how to do it, and it was odd to them at the start too. After a few days trying it, they get the idea and begin to use this approach — in their own style — when they think it’s useful. Right now, you’re probably thinking how dumb I am for not realizing that the display wasn’t supposed to clear yet. I’m thinking how smart I was for having that test to catch me out. It’s all in the point of view.

One other thing on this: no matter how smart you are — and I will say right here that I am hella smart — you will make programming mistakes, and most of them will be dumb. It’s important not to take your dumb moments personally, but to learn from them. Just now I learned that I’m happy to have tests, and that I need to remember to look at them.

Back up – stop clearing on star

OK back to the drawing board. Obviously the star isn’t supposed to do anything. So I can remove the code inside that part of the if. No, really, that’s what I’m going to do:

function Calculator:press(key)
   if key == "*" then

   else
       self.display = self.display..key
   end
end

Guess what! My test runs. Now these last two are failing, like this:

c.press("*")
c:displayIs("12") -- OK
c.press("3")
c:displayIs("3")  -- Displays 123
c.press("=")
c:displayIs("36") -- Displays 123=

So, what to do here? We have to make pressing 3 after star clear out the display and put three into it. (We know this will apply to all of 0 – 9, so I won’t insult us all by just making it work for 3.) So somehow we have to know that a star happened, so that we’ll clear the display before we append to it like always.

I wasn’t sure what the calculator should do, so I ran Dave’s. I noticed that if you type 3*6+2 into it, you get 8. The display, meanwhile, displays “3*6+2″ Well, he said it was still buggy: his point was to show how to do certain things, not to build a real calculator. I kind of like it displaying the whole calculation but if it were to do that I’d like it to work, and that way lies trouble, because when we type 2+3*6 we mean that to be 2 + 18, not 5*6, because operator precedence. We don’t want to go there. No, really, we don’t. That’s a whole different kind of calculator.

Make it clear on next digit after star

So I have to make mine work. I think I’ll save the operator and if a digit comes in when an operator is saved, clear the display and start the append over again. (Yes, I know I’m supposed to do a calculation too but that’s in a future test.)

I had to initialize my new variable, “op” in setup, so now I have this:

function Calculator:init()
   self.display = ""
   self.op = ""
end

function Calculator:press(key)
   if key == "*" then
       self.op = key
   else
       if self.op ~= "" then
           self.display = ""
       end
       self.display = self.display..key
   end
end

Now the only test that’s failing is the =. It displays = and it should display 36. To make this work, when the equal comes up, I need to multiply what was on the screen (the 12) by what is on the screen (the 3). This means I’d better tuck the 12 away, at the same time as I save the star.

Do the math. Finally!

And I’d better handle the = separately too, using it to trigger the arithmetic. So I write this:

function Calculator:press(key)
   if key == "*" then
       self.op = key
       self.temp = self.display
   elseif key == "=" then
       self.display = self.display * self.temp
   else
       if self.op ~= "" then
           self.display = ""
       end
       self.display = self.display..key
   end
end

This gives the surprising result in my test of expected 36 but got 36 !. My guess is that when I do multiply of “12” and “3”, I’m getting a blank in the result. To find out, I’ll improve the test to show some delimiters:

function Calculator:displayIs(string)
   if self.display ~= string then
       local diag = "expected /"..string.."/ but got /"..self.display.."/!"
       print(diag)
   end
end

Much to my momentary surprise, it says “expected /36/ but got /36/!”. So what’s going on? Ah! What’s going on is that the multiply operator returned the number 36 instead of the string “36”, so the test failed. I’m not sure what to do. One simple thing would be to convert my numeric results back to strings. I wonder what would happen, though, if I just ignored the problem. Trouble with that is that I would have to fiddle the tests to deal with “36” versus 36.

I think I’ll just convert back to string. What’s a good way to do that? How about ""..(self.display*self.temp)? That might work … basically appending the number to an empty string in hopes that Codea will convert it for me. Failing that I’m going to have to look something up. Ha! That works. Kind of a hack but I’m happy for now.

By the way, did you notice that "12" * "3" results in 36? Codea converts the strings to numbers before doing the arithmetic. How polite!

Anyway, my first test now runs. Let’s review the whole thing:

First test runs!
-- Article Calc

-- Use this function to perform your initial setup
function setup()
   c = Calculator()
   c:press("1")
   c:displayIs("1")
   c:press("2")
   c:displayIs("12")
   c:press("*")
   c:displayIs("12")
   c:press("3")
   c:displayIs("3")
   c:press("=")
   c:displayIs("36")
end

-- This function gets called once every frame
function draw()
   background(40, 40, 50)
end

Calculator = class()

function Calculator:init()
   self.display = ""
   self.op = ""
end

function Calculator:press(key)
   if key == "*" then
       self.op = key
       self.temp = self.display
   elseif key == "=" then
       self.display = "" .. (self.display * self.temp)
   else
       if self.op ~= "" then
           self.display = ""
       end
       self.display = self.display..key
   end
end

function Calculator:displayIs(string)
   if self.display ~= string then
       local diag = "expected /"..string.."/ but got /"..self.display.."/!"
       print(diag)
   end
end
Story complete. Pause and reflect.

Time to reflect a bit on what just happened. I wrote a short series of tests of the calculator and made them run one by one. I haven’t added any code that wasn’t needed to make those tests work — at least I don’t think so.

That is part of the test-driven development style (TDD) that I use and teach. We never write a line of code that isn’t required by a failing test. So even though I know that there are other ops to worry about, plus minus and so on, I didn’t put them into the if statement. I didn’t cater to anything that wasn’t implied by that test, to the best of my ability.

For this tiny app, it’s not important. When building something larger, this discipline is a nice way to keep from gold-plating things, adding “generality” that isn’t needed. I love to write general code. I have an advanced degree in this stuff and there’s great joy in writing that sort of thing. These days, I take greater joy in letting the program seem to emerge from the fog.

YMMV. I’m not suggesting you should work this way. You might not even want to know this way. But if you want to be a professional programmer these days, it’s valuable to be aware of these approaches. For the folks here, I just hope you find it interesting.

Now what? Well, we need another test. We could do a simple one with + or – or / and we’d learn a bit. But I am inclined to write a harder test, including one of those operators, and to learn from that.

Temptation – operations as anonymous functions

Looking forward, I can see there’s going to be a lot of checking for star and plus and all those. One time to save them in self.op and then probably later to apply them (where I just have a multiply now). I am really tempted to do something nicer than a bunch of if statements. And we are here to learn Codea/Lua, not just to be all up tight and supposedly professional. What if, when we see the star, we stored a function in self.op and when we need to execute that star (or plus or whatever it’ll be) we just executed that function? That might be better.

Now when I’m operating at full discipline, I would build it with if statements and the look at it and find it ugly and improve it. This would be safe and easy, because my tests would support me. It’s a bit against my best principles to put in this idea right now before it has shown to be fully required.

But hey, if you wanted a saint, you should have called someone else. I’m going to try it and see if I like it:

function Calculator:press(key)
   if key == "*" then
       self.op = function(a,b) return a*b end
       self.temp = self.display
   elseif key == "=" then
       self.display = "" .. (self.op(self.display, self.temp))
   else
       if self.op ~= "" then
           self.display = ""
       end
       self.display = self.display..key
   end
end

Note the

self.op = function(a,b) return a*b end

and the corresponding

self.display = "" .. (self.op(self.display, self.temp))

In self.op, I stored an anonymous function returning a*b, and then just called that function when the equal came up. I plan to store similar functions for plus, minus and so on. Will I love this? We’ll see.

Right now, it’s time for a break. Next time, I’ll write a new test that’s a little longer and has another operator or two. We’ll see what happens.

The Next Test

I decided to do a bigger test, basically 450 / 15 – 19, which if my calculations are correct comes to 11. I noticed in writing it that I had not made the calculator instance local in my test. So I’ll provide the full text of the setup() function here.

function setup()
   print("tests begin")
   local c = Calculator()
   c:press("1")
   c:displayIs("1")
   c:press("2")
   c:displayIs("12")
   c:press("*")
   c:displayIs("12")
   c:press("3")
   c:displayIs("3")
   c:press("=")
   c:displayIs("36")

   c = Calculator()
   c:press("4")
   c:displayIs("4")
   c:press("5")
   c:displayIs("45")
   c:press("0")
   c:displayIs("450")
   c:press("/")
   c:displayIs("450")
   c:press("1")
   c:displayIs("1")
   c:press("5")
   c:displayIs("15")
   c:press("-")
   c:displayIs("30")
   c:press("1")
   c:displayIs("1")
   c:press("9")
   c:displayIs("19")
   c:press("=")
   c:displayIs("11")
   print("tests end")
end

It’s getting a bit tedious to write these tests. Often, in this kind of situation, it is. I expect tests for a real calculator object to last for a long time but even so, if it’s a pain I won’t do it. One way to make it easier might be a helper method pressDisplaying(input, output) that would do the press and then check the result. That would save a lot of typing. With a little regex action I could do that here but Codea isn’t as much help on that as some editors.

Anyway, this test calls for implementation of divide and subtract, plus it deals with chaining operations. We’ll see how that goes. I haven’t run the test yet. Stand back, this thing may explode.

First error is “expected /450/ but got /450//!”. And I notice that I can’t tell just which one of my expected 450s this is, but I’m pretty sure it’s the one after the slash, since we know we don’t cater to it and so it’ll be treated as a digit. Makes me think the tests need a number or something. I’ll keep it in mind.

Side Note

Are you amazed or shocked at how little pre-planning or up front design I do, or how I seem to tolerate things being a bit crufty for a while? That’s on purpose. I am confident that my approach will bring all the issues into view, and that I’ll work on the ones that are actually troublesome. And I’ll skip the ones that turn out not to be a burr in my fundament.

This is rather different from the approach described in most of the older software development books, such as Code Complete. There’s great material in those books but we in the Agile movement have observed that with today’s tools and techniques, we can do more and more of our design as we go, not just up front.

I’ve been programming for over half a century (arrgh) and working in this style for 15 years, so I’m pretty comfortable with it. Not that it’s just easy and automatic. I think programming will never be easy, because as my friend Ward Cunningham once said to me, everyone winds up working at the limits of their ability, because people keep piling harder problems on us as we get better. But we can work to keep things simple, if not easy.

Back to the code

I went ahead and put in slash in the same style as times. That caused me to see that order matters for divide and subtract (and power, if I do that). So I renamed the parameters for my anonymous functions to d and t, for display and temp, both in the new divide and back in multiply. It doesn’t change the function, but makes the code more clear and consistent.

function Calculator:press(key)
    if key == "*" then
        self.op = function(d,t) return d*t end
        self.temp = self.display
    elseif key == "/" then
        self.op = function(d,t) return t/d end
    elseif key == "=" then
        self.display = "" .. (self.op(self.display, self.temp))
    else
        if self.op ~= "" then
            self.display = ""
        end
        self.display = self.display..key
    end
end

The tests now run up to “expected /15/ but got /5/!”. This surprises me. In the first test we got two numbers in. But! It was in the first argument, not the second. OK, look at where the digits go in. We’re checking op against “”, and if it isn’t, we’re clearing the screen. That will happen on every press, because the op is still hanging. In addition, we shouldn’t use an empty string test anyway, since op is now a function, not a string.

The behavior we want is that the first digit after an op should clear and then go in, but not the following ones. Also, I noticed that in setting up for divide, I forgot to copy display to temp. So I put it in there. But now I’m wondering if we can combine the clearing and the copying until the first digit after an op. I’ll try it. I plan to add a flag, named first, and do the copy and clear based on that. Here goes.

function Calculator:press(key)
  if key == "*" then
      self.op = function(d,t) return d*t end
      self.first = true
  elseif key == "/" then
      self.op = function(d,t) return t/d end
      self.first = true
  elseif key == "=" then
      self.display = "" .. (self.op(self.display, self.temp))
  else
      if self.first then
          self.temp = self.displat -- typo discovered below!
          self.display = ""
          self.first = false
      end
      self.display = self.display..key
  end
end

With this in place, the tests run with no comment until an error, on line 11, attempt to perform arithmetic on local t. This leads me to the typo above, referring to self.displat. Oops.

function Calculator:press(key)
  if key == "*" then
      self.op = function(d,t) return d*t end
      self.first = true
  elseif key == "/" then
      self.op = function(d,t) return t/d end
      self.first = true
  elseif key == "=" then
      self.display = "" .. (self.op(self.display, self.temp))
  else
      if self.first then
          self.temp = self.display
          self.display = ""
          self.first = false
      end
      self.display = self.display..key
  end
end

Fixing that gives me “expected /30/ but got /15-/!”, which is, of course, the minus failing to be known as an operator.

So we code minus:

elseif key == "-" then
    self.op = function(d,t) return t-d end
    self.first = true

Now we get “expected /30/ but got /15/”. Hmm. I think we clobbered the divide op before doing it! Hey, look, we only actually ever perform an operation on equals! We need to do any pending op before ever putting the next one in.

I also notice a lot of duplicated lines here. Duplication is the code’s way of telling us that there is an idea in our head that is not reflected directly in the code. We’ll want to clean that up soon. But I don’t like to do much code improvement while the code isn’t working. It’s too easy to introduce new errors and not notice them. So I’ll press forward, noting the duplication but living with it until these tests run, if I can. If it gets too hairy, that will be a sign that I’ve bitten off too much. Let’s hope not.

The tests run

And the tests run to completion! I added a doPending() function and used it as needed. Nothing else that I recall:

Calculator = class()

function Calculator:init()
   self.display = ""
   self.op = nil
   self.first = false
end

    function Calculator:press(key)
       if key == "*" then
           self:doPending()
           self.op = function(d,t) return d*t end
           self.first = true
       elseif key == "/" then
           self:doPending()
           self.op = function(d,t) return t/d end
           self.first = true
       elseif key == "-" then
       elseif key == "=" then
           self:doPending()
       else
           if self.first then
               self.temp = self.display
               self.display = ""
               self.first = false
           end
           self.display = self.display..key
       end
    end

    function Calculator:doPending()
       if self.op == nil then return end
       self.display = "" .. (self.op(self.display, self.temp))
       self.op = nil
    end

    function Calculator:displayIs(string)
       if self.display ~= string then
           local diag = "expected /"..string.."/ but got /"..self.display.."/!"
           print(diag)
       end
    end

    function Calculator:draw()
    end

    function Calculator:touched(touch)
    end

Note the new doPending() function. If there’s an op present, it executes it and clears the op. It’s called right before installing an op. Let me mention explicitly the if at the beginning of that function. I could have said if self.op ~= nil then and then done the statements. Same effect. The way I’ve done it there is called “Guard Clause” (see Kent Beck’s books on coding patterns). The idea is that you check any special cases at the top and then exit. If the code got at all complex there, I’d do it with the more usual if/elseif/else, of course. Guard Clause is a pattern I use commonly. If the team’s coding standard uses it, then the team will be used to it. If not, then really no one on the team should be using it. I’m my own team right here, so we do it my way.

Refactoring – duplication means the design needs improvement

As I predicted, we see duplication now. Each of the operators follows the same pattern. Each does any pending op, then puts its own special function into self.op, and then sets the first flag.

As I mentioned, duplication tells us that the code has an idea in it (or our head does) that is not as explicit in the code as it could be. Duplication is the enemy of clear code and the enemy of easy maintenance. If we have this copy-pasted patch of code all over, then when we have to change it — and surely we will — we have to change it everywhere. And we’ll likely miss one. Or worse yet, we might have code that is nearly duplicated, looks the same, but with subtle differences. If we extract the duplicated part, we can see the differences more readily. That gets us to working, clean, maintainable code sooner.

Now that my tests are working, I can clean up the code. In test-driven development (TDD), we call this “Red / Green / Refactor”. When the tests are Red (not running) we do not refactor if we can possibly avoid it. We make the tests go Green. When they run, then we look at the code and see how to improve it. It’s time to do that now. We could wait until we put in plus, and power, or we could do it now. If we wait, there will be more duplication. Right now we have three cases, and that’s usually a good basis for making the improvement. What shall we do? The three offending lines look like this:

       self:doPending()
       self.op = function(d,t) return t-d end
       self.first = true

Each occurrence has a different function in the middle and the other two lines alike. I can think of a number of ways to improve it. Let’s look at doPending() as well, since it’s used in the dups:

function Calculator:doPending()
   if self.op == nil then return end
   self.display = "" .. (self.op(self.display, self.temp))
   self.op = nil
end

What if we change doPending() to accept the function as a parameter. Then it can update the display, set the first flag, and store the new op all at once. Sounds tempting.

However, the equals operator calls doPendng() but doesn’t do the other things. Perhaps it should. It could certainly take nil as the function to set up next, and it seems likely that setting first will be a good idea, since if after displaying the result, the next digit typed does in fact want to clear the display.

The bad news is, there goes my Guard Clause. That didn’t last long this time, but it’s still a good bet because — by my standards of code reading — it’s more clear when it does apply. YMMV of course, as with all of this.

Anyway, doPending(). We’ll pass in a function to be saved away in self.op. We’ll always set the first flag. If there’s an existing op waiting, we’ll execute it, otherwise not. This can be coded in a couple of ways. I could probably save my Guard Clause, but it would have to occur in the middle. That’s not kosher for Guard Clause. So I extend doPending():

function Calculator:doPending(func)
   if self.op ~= nil then
       self.display = "" .. (self.op(self.display, self.temp))
   end
   self.first = true
   self.op = func
end

And then use it:

function Calculator:press(key)
   if key == "*" then
       self:doPending(function(d,t) return d*t end)
   elseif key == "/" then
       self:doPending(function(d,t) return t/d end)
   elseif key == "-" then
       self:doPending(function(d,t) return t-d end)
   elseif key == "=" then
       self:doPending(nil)
   else
       if self.first then
           self.temp = self.display
           self.display = ""
           self.first = false
       end
       self.display = self.display..key
   end
end
It’s alive!

And the tests still run! This gives me great confidence that I haven’t broken anything. The code is pretty clean so far, I’d say. We need to implement the + and ^ operators, and sin and cos if we’re going to copy Dave, but it’s bedtime here at the ranch. I’ll decide tomorrow whether to publish this as one, article, or three. It’s over 5000 words now, so I think three, or even four, might be a good idea. I’ll decide when next I get back to this. For now, everything is solid and rather clean, and I can rest easy.

A Note

Before I go, a note to myself. The else clause in the press() function accepts digits but also any unimplemented operators. We have seen that happen, with the slashes showing up at the end of the display. (Dave’s calc actually does that. I think he intended it, as it shows what’s going to happen in the future. I do not intend it.) Anyway, we should probably limit the else to the digits and put in an else clause that gives us some kind of error if we get an unexpected character. But that’s for tomorrow.

In fact, it was for Friday

Hello, Friday morning here. I’ve been doing other things that I was supposed to be doing. Now let’s see if we can finish up this article, at least to a point where it makes sense to publish it. (Sense by my standards. YMMV.)

I’ve pretty much decided that I’m going to stop with the four operations plus minus times divide, without sin/cos, but I might do them just to show that I can. Or maybe +/-, the unary sign-changing operation, which is commonly present on “four-function” calculators.

What to do

When I return to a project after a day or a month, I look around to see what needs to be done. Sometimes there is an intentionally broken test waiting, to remind me where to go. I did not do that way back Wednesday, because I knew I was leaving for a day or two and I don’t like a system left on a red bar for very long. And anyway I knew that minus was the only operator left untested and unimplemented. No, wait, it’s plus. Wait … two days and I don’t know quite where I left off.

The only way to know is to look at my notes … or the code … or the tests. I’ll pick the tests. Time to review them anyway. They look like this:

-- Article Calc

-- Use this function to perform your initial setup
function setup()
    print("tests begin")
    local c = Calculator()
    c:press("1")
    c:displayIs("1")
    c:press("2")
    c:displayIs("12")
    c:press("*")
    c:displayIs("12")
    c:press("3")
    c:displayIs("3")
    c:press("=")
    c:displayIs("36")

    c = Calculator()
    c:press("4")
    c:displayIs("4")
    c:press("5")
    c:displayIs("45")
    c:press("0")
    c:displayIs("450")
    c:press("/")
    c:displayIs("450")
    c:press("1")
    c:displayIs("1")
    c:press("5")
    c:displayIs("15")
    c:press("-")
    c:displayIs("30")
    c:press("1")
    c:displayIs("1")
    c:press("9")
    c:displayIs("19")
    c:press("=")
    c:displayIs("11")
    print("tests end")
end

With a bit of inspection, I see that there is no test of plus. I also see that the tests are harder to read than I might like. And they were a pain to write. I think I’d prefer something like this:

c:check("4","4")
c:check("5","45")

where check presses the first parameter and checks the display for containing the second. This would readily be implemented by calling the other two functions, of course.

We might also wish to build that function into our testing, rather than into the Calculator. It’s considered to be a bit off to have functions in production code that are only intended for testing. And it would be easy enough to do it in setup.

There are other “nice” things we might do with the tests. We could have a checkBegin and checkEnd function, for example, that might print something like “….X.X.” if tests 1-4, 6, and 8 passed, but 5 and 7 did not. The fact that the tests print nothing when everything is OK is a bit scary.

Why do you bring this up?

Good question. I bring this up because, today, the top “Agile” teams actually think about this stuff and do something about it. With modern refactoring tools it’s easy to make changes like this, and if we were going to be looking at this code for months, making it easier to understand is worth the effort

So I mention it because part of my purpose in life is to let people know how things are being done. I’m not saying you need to do them. I’m just explaining what I do, what other “Agilists” do, and why we do them. Then you get to see the code and the results and decide for yourself what, if anything, is worth trying. I hope you’ll try a lot of these ideas, but I don’t get paid any more — or any less — if you don’t.

Anyway, plus …

I’m feeling pressure to get this article out. And that pressure, self-imposed though it is, is telling me not to clean up the tests but to Build That Feature. And that’s what I’m going to do. But I’m aware that even a tiny bit of self-imposed pressure is enough to cause me to slack a bit on the things that I know darn well make my code more able to be changed in the future.

You have to make trade-offs. I’m making this one. But even now, there’s a bit of me whispering that I’m doing the wrong thing. Hell, I could have fixed the tests up by now.

Oh, OK, stop nagging. First I’ll fix the tests. Hold on.

That was grueling …

I decided to do the change at 9:40. It’s 9:44. I took the code into Sublime, did a find/replace with a regular expression, and now it looks like this:

-- Article Calc

-- Use this function to perform your initial setup
function setup()
    print("tests begin")
    local c = Calculator()
    c:check("1","1")
    c:check("2","12")
    c:check("*","12")
    c:check("3","3")
    c:check("=","36")

    c = Calculator()
    c:check("4","4")
    c:check("5","45")
    c:check("0","450")
    c:check("/","450")
    c:check("1","1")
    c:check("5","15")
    c:check("-","30")
    c:check("1","1")
    c:check("9","19")
    c:check("=","11")
    print("tests end")
end

I’ll paste that back to Codea. It will fail for lack of check, which I’ll implement:

function Calculator:check(key, result)
    self:press(key)
    self:displayIs(result)
end

And Bob’s your uncle, whatever that means. Anyway it was totally easy and took just a few minutes to do. And I feel better now. Lesson learned? Probably not, I am perpetually lazy. The moment you guys look away I’m gonna do something lazy. Trust me.

CloudClip

By the way, got a neat free tool called CloudClip Manager, for the iPad and the Mac. It shares the clipboard across iCloud. So I can copy something on my Mac (where I’m writing this) and paste it into Codea. Or vice versa.

Because the iPad doesn’t multi-task at all well, you have to flip into CloudClip to get it to refresh through iCloud but it is still ten times easier than mailing the code to yourself or whatever I used to be doing. Recommended product. I have nothing to do with it and do not get a percentage of the (free) price. Or 100 percent of it. I forget.

Plus. We were going to do plus.

I think I’ll just add a plus operation to an existing test. That should be good enough to get plus working. Then maybe I’ll add another test. So, looking at the last test above, we end up with 11. I could add a +5 before the = and get 16. Or, might be interesting to add the +5 after the = just to see what it does. I’ve not specified that.

I’m going to try it but when it fails, I’m going back to before the = and get that working first, because otherwise I’d be building two features at once, plus and input after equal. That would be bad. Here goes …

Well, the first thing that happens is “Expected 11 but got +”. We know that’s because plus doesn’t work at all yet. So I’ll put in the obvious lines for plus.

And the tests run! Woot! Here’s all the code:

--# Calculator
Calculator = class()

function Calculator:init()
    self.display = ""
    self.op = nil
    self.first = false
end

function Calculator:press(key)
    if key == "*" then
        self:doPending(function(d,t) return d*t end)
    elseif key == "/" then
        self:doPending(function(d,t) return t/d end)
    elseif key == "-" then
        self:doPending(function(d,t) return t-d end)
    elseif key == "+" then
        self:doPending(function(d,t) return t+d end)
    elseif key == "=" then
        self:doPending(nil)
    else
        if self.first then
            self.temp = self.display
            self.display = ""
            self.first = false
        end
        self.display = self.display..key
    end
end

function Calculator:check(key, result)
    self:press(key)
    self:displayIs(result)
end

function Calculator:doPending(func)
    if self.op ~= nil then
        self.display = "" .. (self.op(self.display, self.temp))
    end
    self.first = true
    self.op = func
end

function Calculator:displayIs(string)
    if self.display ~= string then
        local diag = "expected /"..string.."/ but got /"..self.display.."/!"
        print(diag)
    end
end

function Calculator:draw()
end

function Calculator:touched(touch)
end

--# Main
-- Article Calc

-- Use this function to perform your initial setup
function setup()
    print("tests begin")
    local c = Calculator()
    c:check("1","1")
    c:check("2","12")
    c:check("*","12")
    c:check("3","3")
    c:check("=","36")

    c = Calculator()
    c:check("4","4")
    c:check("5","45")
    c:check("0","450")
    c:check("/","450")
    c:check("1","1")
    c:check("5","15")
    c:check("-","30")
    c:check("1","1")
    c:check("9","19")
    c:check("=","11")
    c:check("+","11")
    c:check("5","5")
    c:check("=","16")
    print("tests end")
end

Notice the check for + 5, there at the end.

Summing Up

Are we done? Well, we’re probably all more than done reading this article, but if we were building a production calculator, we can think of more things to do. There certainly could be more functions, change sign, sine, cosine, arc-cotangent, and so on. Two- and three-dimensional plotting. I don’t know: the people who want products think of a lot of stuff. That’s up to whoever is deciding what the product needs to do.

Right now, that’s me, and I’ve decided the product has done its job, which is to serve as a platform for talking about how I might implement something in Codea.

But there are things we might yet do if this were a real business project. First, we might want more tests. These were the bare minimum. We might want to deal with errors like dividing by zero, or errors like typing one operator after another. And so on. We should test all those and make them do whatever we decide is right.

That can get bloody tedious. That’s why programmers in real life get paid, I suppose. But frankly, I’d rather do this than ship a product that has bugs in it, and I’d rather code this way than leave code lying around for the unsuspecting future me to look at and go WTF????

Practices — and do you really do this??

Let’s look at some of the key aspects of what I’ve done in this exercise.

Quick Design

First, I started with a little bit of design. I drew a picture of how I thought a calculator works. Remember that I got it wrong. The more we design without feedback, the more we get bits wrong. We’re tempted to say “we should have designed more”, but I believe the truth is “we should have gotten concrete feedback sooner”.

Begin with tests

Then, I did move quickly to an implementation. I started with tests. Automated tests cause me to think a bit more carefully about what I’m doing, and they can be run again and again to be sure I don’t break anything. And once in a while, when a test “fails”, I look at it and realize that my expectation as expressed in the test is wrong: my understanding of what I’m doing is wrong.

When a test fails, I always learn something. Usually I learn that I’ve not yet built a feature. Sometimes I learn that I’ve broken an old feature. Sometimes I learn that I don’t know what I want. Sometimes I learn that I fumble-fingered in the test or in the code. It’s all good. When the tests work, I have growing confidence in the program, and when they fail, it alerts me to an incoming learning.

Build from a simple (nearly stupid) design

Remember that I started by just appending every key press to the displayed answer. Some would call that stupid: we in the Agile programming universe call it simple. (Sometimes we return a constant for a variable answer. If it’s the correct constant for our current test, we call that pattern “Fake it til you make it”. I don’t think I did that here.)

Appending the key press isn’t wrong … it’s just wrong sometimes. So I do it, and some tests pass. When one fails, I’ve discovered when “sometimes” is.

Just make the test pass

Now, trust me, I am fairly good at programming, so I really did know that times was going to show up in the display, and that that was bad. But I didn’t code for that. I coded to make the next test pass.

What I do is make the test pass with the simplest code I can write. Not bad code, but simple. I make the code “more nearly” do the right thing. Inch by inch, step by step (slowly he turned), I make the program work, guided by my tests. I try never to write a line of code that isn’t required by the test I’m working on.

Refactor to make the code clean

I’m always watching for code that is not clean. It might be in my tests, and it will certainly be in the production code.

When my tests are green — all running — I look for ways to improve it. I changed the code to use an anonymous function at one of those points, and it worked out well.

Avoid the esoteric

Anonymous functions are pretty popular these days, in some circles, but to some programmers they are quite odd because they may have never used a language where they are possible.

I don’t use them often myself so I wanted to try it. Against doing that was my own lack of practice, and the fact that I’m kind of writing to beginners with Codea. In favor of doing it was that it’s an important thing to be good at in Lua, and that I had my tests to guide me.

Is the anonymous function too esoteric for you? Then don’t do it. And if you do decide to try something cool, make sure it’s surrounded by tests. Some teams have a rule that if anyone every writes something “cool”, it has to be deleted. Cool code is the code that bites you at 2 AM when you are called in to get the system back up.

So, use judgment.

Bottom line — nearly

All these words aside, if you’ll think about what we did here, it went incredibly smoothly. We wrote some tests, made them work one after another, worked very simply, cleaned up the code as we went. We had no long debugging or “what the heck is going on” sessions.

Click click click. That’s how it goes when I work this way. Might it work for you? I think it might.

Enough already

OK, this is more than enough for a single article. But I’ve decided not to split it apart. I’ll warn readers at the top to consider small bites. If you made it all the way down here, congratulations and thanks for reading.

You can offer feedback on the codea.io forums if you’re a member, or drop me an email. If there are interesting questions, I’ll update this or write a follow-up. For now, thanks for tuning in.

Categories: Blogs

The Agile Reader – Weekend Edition: 10/10/2014

Scrumology.com - Kane Mar - Fri, 10/10/2014 - 10:20

You can get the Weekend Edition delivered directly to you via email by signing up http://eepurl.com/0ifWn.

The Weekend Edition is a list of some interesting links found on the web to catch up with over the weekend. It is generated automatically, so I can’t vouch for any particular link but I’ve found the results are generally interesting and useful.

  • Cynical Agile and Scrum Dictionary – Yuriy Zubarev #LOL #Fun
  • RT @velkan12: great video about agile work flow #uzility #agile #kanban #scrum @UzilitySoftware
  • #Accenture is hiring! Agile Methods (Scrum/FDD/XP/Crystal/DSDM) in #Kolkata, apply now! #job http://t.co/APOkPL5c4E
  • New #job opening at #Accenture in #Kolkata! Agile Methods (Scrum/FDD/XP/Crystal/DSDM) http://t.co/HNDrDB5jYS
  • Agile Methods (Scrum/FDD/XP/Crystal/DSDM) needed in #Kolkata, apply now at #Accenture! #job http://t.co/J8EA4sSMW2
  • Agile Methods (Scrum/FDD/XP/Crystal/DSDM) needed in #Kolkata, apply now at #Accenture! #job http://t.co/cq0jRBBEqV
  • Agile Methods (Scrum/FDD/XP/Crystal/DSDM) (#job) wanted in #Kolkata. #Accenture http://t.co/nxNrcH441O
  • Apply now to work for #Accenture as Agile Methods (Scrum/FDD/XP/Crystal/DSDM)! (#Kolkata) #job http://t.co/p7YkCMXHO2
  • How to Plan an Agile Sprint Meeting? – http://t.co/RDht7k2Quw
  • Check out this #job: Agile Methods (Scrum/FDD/XP/Crystal/DSDM) at #Accenture (#Kolkata) http://t.co/gvDp7Ebrwp
  • Apply now to work for #Accenture as Agile Methods (Scrum/FDD/XP/Crystal/DSDM)! (#Kolkata) #job http://t.co/sfvfCKO7nP
  • Apply now to work for #Accenture as Agile Methods (Scrum/FDD/XP/Crystal/DSDM)! (#Kolkata) #job http://t.co/nbresrR6fT
  • #Accenture is hiring an Agile Methods (Scrum/FDD/XP/Crystal/DSDM), apply now! (#Kolkata) #job http://t.co/9YuKpxFYgf
  • @rkasper But wait- there’s more #agile #scrum #lean #management #innovation #leadership #triballeadership
  • How to be a Product Owner in 3 Steps — — #agile #scrum http://t.co/jUrGElkP3r
  • Try TargetProcess3 — fascinating agile project management software #targetprocess #kanban #scrum
  • New #job opening at #Accenture in #Kolkata! Agile Methods (Scrum/FDD/XP/Crystal/DSDM) http://t.co/kZJHjnRiTB
  • Apply now to work for #Accenture as Agile Methods (Scrum/FDD/XP/Crystal/DSDM)! (#Kolkata) #job http://t.co/oweptJLVwW
  • Agile by McKnight, Scrum by Day is out! Stories via @spencerhurst @SaraHitchcock
  • 5 Myths About #DevOps… And One Hard Truth via @Champagnie #Agile #PM #Scrum
  • RT @AstrolabeMe: Cynical Agile and Scrum Dictionary – Yuriy Zubarev #LOL #Fun
  • RT @mscurah: 5 Myths About #DevOps… And One Hard Truth via @Champagnie #Agile #PM #Scrum
  • Medical Mutual: Web Business Analyst – Agile Scrum Master 14-267 (#Strongsville, OH) #IT #Job #Jobs
  • RT @mscurah: 5 Myths About #DevOps… And One Hard Truth via @Champagnie #Agile #PM #Scrum
  • RT @mscurah: 5 Myths About #DevOps… And One Hard Truth via @Champagnie #Agile #PM #Scrum
  • I liked a @YouTube video Best Online Agile Scrum Project Management Methodology Certification
  • #Accenture is hiring an Agile Scrum #Master in #SanFrancisco, apply now! #job http://t.co/paRu7PGY3H
  • RT @MasterScrum: The Lorax Would Be a Great Product Owner!
    Lessons in #scrum from a Dr Seuss classic. #agile
    http://…
  • RT @yochum: Spotify engineering culture (part 2) #agile #scrum #startup http://t.co/yo5LFi6ffc
  • RT @yochum: Spotify engineering culture (part 2) #agile #scrum #startup http://t.co/yo5LFi6ffc
  • RT @yochum: Spotify engineering culture (part 1) #agile #scrum #startup http://t.co/vLrxNsGCxq
  • Keep it Simple: What is Agile SCRUM: #scrum #agile
  • RT @AstrolabeMe: Cynical Agile and Scrum Dictionary – Yuriy Zubarev #LOL #Fun
  • RT @FreeScrumEbook: Keep it Simple: What is Agile SCRUM: #scrum #agile
  • Your stuff is too big make it smaller! #agile #scrum #thatsIntelligence
  • RT @christianlmiles: Your stuff is too big make it smaller! #agile #scrum #thatsIntelligence
  • Managing in Agile – Introducing Scope Changes
    via @AgilePJ
    #PMI-ACP#Agile#Scrum
  • #Scrum vs. #Kanban – an interesting discussion… #ScrumvsKanban #Agile
  • RT @terealvarezv: “@ShirlyRonenRL: AgiloPedia: #Stattys – Write & Slide #scrum #agile” ~~ #worthwatching
  • Agile Canada » Project Manager & Scrum Master – Colligo Networks – Vancouver, BC: Evange… #Canada #Agile #Jobs
  • #DevOps team? DevOps toolchains! #agile #scrum http://t.co/F1NlEriG1s
  • RT @Neomobile_Group: #DevOps team? DevOps toolchains! #agile #scrum http://t.co/F1NlEriG1s
  • RT @CriticalMfg: Yes, we’re #lego fans RT @CriticalMfg: Scrum training @ Critical Manufacturing #scrum #agile http:/…
  • Plus d’infos sur TV du stand @sii_ouest #atrennes #managementVisuel #calottes cc @msieur_tim http://t.co/kegUvh7Zwa
  • New #job: Business Analyst – Ecommerce / Agile / Scrum / Web Applications,Chester .. #jobs
  • RT @yochum: 10 Things You Could Do When You’re Done Writing Code #agile #scrum
  • Categories: Blogs

    Empower Teams to Increase Quality

    Ben Linders - Fri, 10/10/2014 - 09:29
    When an organization is experiencing quality problems with their products, agile software development often isn't the first solution that comes up in people's minds. Often I see people trying to address them using classical waterfall based approaches, only to find out that it will make problems even worse. I recommend agile, not only to deliver working software faster but also with the right quality. This posts shows how empowering the team helps to increase the quality of product. Continue reading →
    Categories: Blogs

    Post Mortem Magazine

    Agile Tools - Fri, 10/10/2014 - 09:23

    console-controller-games-498-825x550

    Years ago I used to read a magazine called Game Development (at least I think that was it). I’ve never worked in game development myself, but I found it fascinating to take a little peek into the world of the game development teams. They were always working on some cutting edge game engine technology that enabled “the next generation of jaw dropping graphics” and some form of ridiculously enhanced gaming experience. At the time it seemed to me like the game developers were very much the real deal – the applications I wrote were childish by comparison. The level of performance optimization they engaged in was astronomical compared to anything I dealt with. The geometry they used to describe the 3D worlds they created was a language all it’s own. It looked like all the cool kids were in gaming.

    There was a regular article in the magazine called something clever like “Post Mortem”. Every month they would publish a post mortem written by a project manager or team that had just released a new game. These were not happy-go-lucky-aren’t-we-cool reports. No, these were unflinching, unsparing critiques of all that happened on the project. There was drama, daunting challenges, and total train wrecks. This stuff was riveting!

    I used to think to myself, “Everybody should be doing this!” I was already working on agile projects at the time. I was dutifully doing a team retrospective every 2 weeks, but I never got the nerve to publish one. I probably should have, but I didn’t think at the time that our stuff would be all that interesting (in hindsight I have had my fair share of project train wrecks). Nobody else published post mortems either. This gaming magazine was the only place I’ve seen them widely published.

    It would be interesting to have a magazine composed of just project post mortems and retrospectives. In a very real way it would be a collection of experimental results. Some of those experiments would be successes and many would be failures, and each and every one of them would be useful.

    Of course who would read such a publication? Project Management geeks? Scrum Masters? And what would we advertise in this little catalog of triumphs and disasters? Anti-depressants? Liquor? Well, all kidding aside, I really do think it would be useful. Of course nobody makes magazines anymore. It would have to be a blog or something. Not a bad idea really. Hmmm…


    Filed under: Agile Tagged: Agile, development, Games, gaming, post mortem, retrospectives, Teams
    Categories: Blogs

    The LGPL on Android

    Xebia Blog - Fri, 10/10/2014 - 09:11

    My client had me code review an Android app built for them by a third party. As part of my review, I checked the licensing terms of the open source libraries that it used. Most were using Apache 2.0 without a NOTICE file. One was using the GNU Lesser General Public License (LGPL).

    My client has commercial reasons to avoid Copyleft-style licenses and so I flagged the library as unusable. The supplier understandably was not thrilled about the rework that implied and asked for an explanation and ideally some way to make it work within the license. Looking into it in more detail, I'm convinced that if you share my client's concerns, then there is no way to use LGPL licensed code on Android. Here's why I believe this to be the case.

    The GNU LGPL

    When I first encountered the LGPL years ago, it was explained to me as “the GPL, without the requirement to publish your source code”. The actual license terms turn out to be a bit more restrictive. The LGPL is an add-on to the full GPL that weakens (only) the restrictions to how you license and distribute your work. These weaker restrictions are in section 4.

    Here's how I read that section:

    You may convey a Combined Work under terms of your choice that […] if you also
    do each of the following:
      a) [full attribution]
      b) [include a copy of the license]
      c) [if you display any copyright notices, you must mention the licensed Library]
      d) Do one of the following:
        0) [provide means for the user to rebuild or re-link your application against
           a modified version of the Library]
        1) [use runtime linking against a copy already present on the system, and allow
           the user to replace that copy]
      e) [provide clear instructions how to rebuild or re-link your application in light
         of the previous point]

    The LGPL on Android

    An Android app can use two kinds of libraries: Java libraries and native libraries. Both run into the same problem with the LGPL.

    The APK file format for Android apps is a single, digitally signed package. It contains native libraries directly, while Java libraries are packaged along with your own bytecode into the dex file. Android has no means of installing shared libraries into the system outside of your APK, ruling out out (d)(1) as an option. That leaves (d)(0). Making the library replaceable is not the issue. It may not be the simplest thing, but I'm sure there is some way to make it work for both kinds of libraries.

    That leaves the digital signature, and here's where it breaks down. Any user who replaces the LGPL licensed library in your app will have to digitally sign their modified APK file. You can't publish your code signing key, so they have to sign with a different key. This breaks signature compatibility, which breaks updates and custom permissions and makes shared preferences and expansion files inaccessible. It can therefore be argued that such an APK file is not usable in lieu of the original app, thus violating the license.

    In short

    The GNU Lesser General Public License ensures that a user has freedom to modify a so licensed library used by your application, even if your application is itself closed source. Android's app packaging and signature requirements are such that I believe it is impossible to comply with the license when using an LGPL licensed library in a closed source Android app.

    Categories: Companies

    Die Sache mit der Freiwilligkeit

    Scrum 4 You - Fri, 10/10/2014 - 07:30

    Ich war diesen Sommer in London auf Urlaub. Und ja so wie es sich für das Londoner Wetter gehört, gab es auch im Sommer viel Regen. Nun gut, was tun im Regen? Am besten in eines der tollen Museen gehen. Die große Überraschung: Man kann die einige Stockwerke umfassenden Standard-Ausstellungen gratis besuchen! Am Ausgang ist es jedem selbst überlassen, ob er an das Museum Geld spenden möchte. Alle Mitarbeiter betonen immer wieder, dass man völlig freiwillig spenden kann und keinerlei Zwang herrscht.

    Für mich als Wienerin war das tatsächlich etwas ungewohnt. Drei Museen später leuchtete es mir aber immer mehr ein: Ich hatte in den letzten drei Museen viel mehr gespendet als den Richtwert, den die Museen vorgeschlagen hatten. Ich wusste nicht so richtig warum, aber ich genoss jede Ausstellung viel leichter und ungezwungener (ich hatte ja auch keine Unmengen für den Eintritt gezahlt). Beim Rausgehen spendete ich wegen der guten Erfahrung und der mir zugestandenen Freiwilligkeit also viel mehr.

    Das Thema der Freiwilligkeit taucht immer wieder in vielen Scrum-Teams auf. Soll es eine Anwesenheitspflicht geben für die Dailys, Sprint Plannings, Reviews und Retrospektiven? Viele sagen, es herrsche absolute Anwesenheitspflicht, jeder habe zu erscheinen, da sich das Team sonst nicht selbst organisieren könne. In vielen Teams werden Einladungen für alle Meetings versendet und es wird erwartet, dass man teilnimmt. Da ist von Freiwilligkeit keine Rede.

    Vor einigen Wochen habe ich einen Kollegen getroffen, der mir von einem Team erzählte, mit dem er anfangs als ScrumMaster Schwierigkeiten hatte. Das war für mich nichts Überraschendes, bis er erwähnte, er hätte den Teammitgliedern von Anfang an gesagt, sie müssten nicht in die Meetings kommen. Sie würden zu 100 % auf Freiwilligkeit beruhen. In der Runde herrschte Verwunderung: Wie sollten denn die Meetings funktionieren, wenn die Leute keine Lust hätten und dann auch noch alles auf ihrer Freiwilligkeit beruhte?

    Der Kollege meinte nur, dass innerhalb eines Sprints alle Teammitglieder zu den Dailys dazugestoßen seien. Sie wären pünktlich gewesen und hätten alle Scrum gemacht – bis auf einen. Dieses eine Teammitglied nahm auch nach zwei Sprints nicht an den Dailys teil, sah sich das Taskboard an und beendete seine Storys zeitgerecht. Er nahm aber nur an den Meetings teil, an denen er teilnehmen wollte. Im dritten Sprint nahm er am Daily teil, in dem er bisher nur zugesehen hatte. Im vierten Sprint schrieb er bereits eigene Tasks. Im fünften Sprint half er dem PO mit komplexeren Storys, die in seinem Fachgebiet lagen. Inzwischen sind fast sechs Monate vergangen, das komplette Team nimmt an allen Meetings teil und organisiert sich selbst ganz freiwillig.

    Man muss Menschen manchmal etwas mehr Vertrauen schenken, als man vermutlich möchte, aber es zahlt sich aus. Alle Museen in London können sich durch die freiwilligen Spenden ihrer Besucher erhalten.
    Jeder spendet so viel wie er kann oder will – und siehe da, es ist möglich.

    Related posts:

    1. ScrumMeetings moderieren oder „ein ScrumMaster hat nichts zu tun“
    2. Klassiker | Sprint Planning
    3. Certified ScrumMaster class in Wien | 5 Mai 2008

    Categories: Blogs

    VersionOne and CA Technologies Partner on Agile Project Management

    Scrum Expert - Thu, 10/09/2014 - 18:42
    CA Technologies and VersionOne have unveiled a PPM (Project & Portfolio Management) and Agile project management solution integration that gives technology leaders the insight to strategically plan, manage and track both Agile and waterfall project portfolios from concept to completion in a single console. Available today, native integration between the latest release of CA PPM (formerly CA Clarity™ PPM) and the VersionOne® Agile project management solution helps software organizations extend upstream visibility of Agile projects, presenting them as prioritized strategic investments into their overall portfolio planning, funding and resource management process. Portfolio ...
    Categories: Communities

    Agile Scrum Master, Square One Resources , Norwich, UK

    Scrum Expert - Thu, 10/09/2014 - 18:00
    Agile Scrum Master is immediately required by leading global organisation based in Norwich. Extensive experience working as an Scrum Master is required. Experience sharing scrum initiatives through the whole organization, collaborating with the rest of Scrum Masters. Great communication and coaching skills, a good story teller. Passionate about Agile and lean ways of working, passionate about team dynamics. Good understanding of the software development process. Really cares about people, know how to motivate people and help the team to be high performance. Challenge the team when needed. Ability to coach individuals and ...
    Categories: Communities

    10 Things You Could Do When You’re Done Writing Code

    Agile Management Blog - VersionOne - Thu, 10/09/2014 - 16:45

    So you’re two-thirds of the way through your iteration and there are no more development tasks to complete. Nice work! Understandably, your instinct is to pull another story into the iteration, but doing so has risks and disadvantages. When you add additional work into the iteration, you’re increasing the batch size. This causes additional complication due to increased changes in the code base. It usually results in carryover, which has a demoralizing effect on the team. And it eliminates an opportunity to get feedback on the emergent product before additional work is embarked on.

    Remember, the iteration was planned so that all members of the team can function at optimum efficiency, not so that the developers can program at optimum efficiency (Yes, there is a difference).

    Before you peek into your product owner’s backlog and working on something outside the iteration plan, have a look at this list and consider doing one or more of these things instead:

    1.  Refactor something you recently wrote
    2.  Add unit tests to an uncovered area of code
    3.  Find a technical tutorial on the Internet
    4.  Offer to pair with a developer on another team
    5.  Estimate open items in the backlog
    6.  Create some automated functional tests
    7.  Clean your desk
    8.  Ask your product owner about the next release
    9.  Help your product owner create acceptance criteria for items in the backlog
    10. Implement a prioritized improvement suggestion from the last retrospective

    This isn’t an exhaustive list. What am I missing? Let’s see how many more items we can add to it. Give me your ideas in the comments, or tweet them – @johnkrewson.

    Categories: Companies

    Project Goals using Effects or Feature List

    Dear Junior
    There has always been two ways to set goals for a project, either you can define the goal of the project to be a list of feature to be implemented, or you can define some effect you want to see. Both of these have been around for a long time, and effect goals have always been superior. 
    Setting goals as a feature list is actually pretty simple - you simply state "these features I want to see before we consider this project closed". An online bookstore could say that it wants search-by-author, categories, and others-have-bought recommendations.
    Following up during the project will simply consists of checking how far on this check-list the development team has progressed.
    Effect goals are a little bit harder to set. You have to figure out and express why you want to have work done, what purpose it fulfils, in what way it makes your world better. Said bookstore must then express that it hopes people each customer will by 0.35 more books per checkout on average, or that it will increase its customer base with 10 000 new customers.
    Following up during the project using this approach will consist of measuring the business parameters and watch the values change. A tricky part is that the full impact of the project might not be seen until the development work is "finished" (whatever that means), or even not until some time thereafter.
    To put things a little bit into context, it is not the "bookstore" that starts a project - it is always a person involved, in this case probably the product owner of the online store. And, this is the person who should explain why she is about to spend a lot of peoples' time and a lot of the organisation's money.
    I have always found that measuring success on effect, or impact, is the more intellectually honourable approach. To be frank, setting goals as a feature list does really say "this much work I want to have done" or rephrased "this much money I want to spend", nothing about what value it should result in. And if you want to have a group of people to work to bring your ideas to come real, the least you can do is to explain to them the value you think it will bring. Setting goals on effect is really about that - bringing purpose to the work.

    Now, these two ways of setting goals and measuring success have a fundamental impact on how to manage projects in an agile manner, but that will have to wait until a later letter.
    Yours
       Dan
    Categories: Blogs

    Function references in Swift and retain cycles

    Xebia Blog - Thu, 10/09/2014 - 15:49

    The Swift programming language comes with some nice features. One of those features are closures, which are similar to blocks in objective-c. As mentioned in the Apple guides, functions are special types of closures and they too can be passed around to other functions and set as property values. In this post I will go through some sample uses and especially explain the dangers of retain cycles that you can quickly run into when retaining function pointers.

    Let's first have a look at a fairly simple objective-c sample before we write something similar in Swift.

    Objective-c

    We will create a button that executes a block statement when tapped.

    In the header file we define a property for the block:

    @interface BlockButton : UIButton
    
    @property (nonatomic, strong) void (^action)();
    
    @end
    

    Keep in mind that this is a strong reference and the block and references in the block will be retained.

    And then the implementation will execute the block when tapped:

    #import "BlockButton.h"
    
    @implementation BlockButton
    
    -(void)setAction:(void (^)())action
    {
        _action = action;
        [self addTarget:self action:@selector(performAction) forControlEvents:UIControlEventTouchUpInside];
    }
    
    -(void)performAction {
        self.action();
    }
    
    @end
    

    We can now use this button in one of our view controllers as following:

    self.button.action = ^{
        NSLog(@"Button Tapped");
    };
    

    We will now see the message "Button Tapped" logged to the console each time we tap the button. And since we don't reference self within our block, we won't get into trouble with retain cycles.

    In many cases however it's likely that you will reference self because you might want to call a function that you also need to call from other places. Let's look as such an example:

    -(void)viewDidLoad {
        self.button.action = ^{
            [self buttonTapped];
        };
    }
    
    -(void)buttonTapped {
        NSLog(@"Button Tapped");
    }
    

    Because our view controller (or it's view) retains our button, and the button retains the block, we're creating a retain cycle here because the block will create a strong reference to self. That means that our view controller will never be deallocated and we'll have a memory leak.

    This can easily be solved by using a weak reference to self:

    __weak typeof(self) weakSelf = self;
    self.button.action = ^{
        [weakSelf buttonTapped];
    };
    

    Nothing new so far, so let's continue with creating something similar in Swift.

    Swift

    In Swift we can create a similar Button that executes a closure instead of a block:

    class ClosureButton: UIButton {
    
        var action: (() -> ())? {
            didSet {
                addTarget(self, action: "callClosure", forControlEvents: .TouchUpInside)
            }
        }
    
        func callClosure() {
            if let action = action {
                action()
            }
        }
    }
    

    It doing the same as the objective-c version (and in fact you could use it from objective-c with the same block as before). We can assign it an action from our view controller as following:

    button.action = {
        println("Button Tapped")
    }
    

    Since this closure doesn't capture self, we won't be running into problems with retain cycles here.

    As mentioned earlier, functions are just a special type of closures. Which is pretty nice, because it lets us reference functions immediately like this:

    override func viewDidLoad() {
        button.action = buttonTapped
    }
    
    func buttonTapped() {
        println("Button Tapped")
    }
    

    Nice and easy syntax and good for functional programming. If only it wouldn't give us problems. Without it being immediately obvious, the above sample does create a retain cycle. Why? We're not referencing self anywhere? Or are we? The problem is that the buttonTapped function is part of our view controller instance. So when the button.action references to that function, it creates a strong reference to the view controller as well. In this case we could fix it by making buttonTapped a class function. But since in most cases you'll want to do something with self in such a function, for example accessing variables, this is not an option.

    The only thing we can do to fix this is to make sure that the button won't get a strong reference to the view controller. Just like in our last objective-c sample, we need to create a weak reference to self. Unfortunately there is no easy way to simply get a weak reference to our function. So we need a work around here.

    Work around 1: wrapping in closure

    We can create a weak reference by wrapping the function in a closure:

    button.action = { [weak self] in
        self!.buttonTapped()
    }
    

    Here we first create a weak reference of self. And in Swift, weak references are always optional. That means self within this closure is now an optional and need to unwrap it first, which is what the exclamation mark is for. Since we know this code cannot be called when self is deallocated we can safely use the ! instead of ?.

    A lot less elegant than immediately referencing our function immediately.

    In theory, using an unowned reference to self should also work as following:

    button.action = { [unowned self] in
        self.buttonTapped()
    }
    

    Unfortunately (for reasons unknown to me) this crashes with a EXC_BAD_ACCESS upon deallocation of the ClosureButton. Probably a bug.

    Work around 2: method pointer function

    Thanks to a question on StackOverflow about this same problem and an answer provided by Rob Napier, there is a way to make the code a bit more elegant again. We can define a function that does the wrapping in a closure for us:

    func methodPointer<T: AnyObject>(obj: T, method: (T) -> () -> Void) -> (() -> Void) {
        return { [weak obj] in
            method(obj!)()
        }
    }
    

    Now we can get a weak reference to our function a bit easier.

    button.action = methodPointer(self, ViewController.buttonTapped)
    

    The reason this works is because you can get a reference to any instance function by calling it as a class function with the instance (in this case self) as argument. For example, the following all does the same thing:

    // normal call
    self.buttonTapped()
    
    // get reference through class
    let myFunction = MyViewController.buttonTapped(self)
    myFunction()
    
    // directly through class
    MyViewController.buttonTapped(self)()
    
    

    However, the downside of this is that it only works with functions that take no arguments and return Void. i.e. methods with a () -> () signature, like our buttonTapped.

    For each signature we would have to create a separate function. For example for a function that takes a String parameter and returns an Int:

    func methodPointer<T: AnyObject>(obj: T, method: (T) -> (String) -> Int) -> ((String) -> Int) {
        return { [weak obj] string in
            method(obj!)(string)
        }
    }
    

    We can then use it the same way:

    func someFunction() {
        let myFunction = methodPointer(self, MyViewController.stringToInt)
        let myInt = myFunction("123")
    }
    
    func stringToInt(string: String) -> Int {
        return string.toInt()
    }
    
    Retain cycles within a single class instance

    Retain cycles do not only happen when strong references are made between two instances of a class. It's also possible, and probably less obvious, to create a strong reference within the same instance. Let look an an example:

    var print: ((String) -> ())?
    
    override func viewDidLoad() {
        print = printToConsole
    }
    
    func printToConsole(message: String) {
        println(message)
    }
    

    Here we do pretty much the same as in our button examples. We define an optional closure variable and then assign a function reference to it. This creates a strong reference from the print variable to self and thus creating a retain cycle. We need to solve it by using the same tricks we used earlier.

    Another example is when we define a lazy variable. Since lazy variables are assigned after initialisation, they are allowed to reference self directly. That means we can set them to a function reference as following:

    lazy var print: ((String) -> ()) = self.printToConsole
    

    Of course this also creates a retain cycle.

    Conclusion

    To avoid creating retain cycles in Swift you should always remember that a reference to an instance function means that you're referencing the instance as well. And thus when assigning to a variable, you're creating a strong reference. Always make sure to wrap such references in a closure with a weak reference to the instance or make sure to manually set the variables to nil once you're done with them.

    Unfortunately Swift does not support weak closure variables, which is something that would solve the problem. Hopefully they will support it in the future or come up with a way to create a weak reference to a function much like we can use [weak self] now in closures.

    Categories: Companies

    Small Internal Releases Lead to Happy Customers

    Johanna Rothman - Thu, 10/09/2014 - 15:42

    If you saw Large Program? Release More Often, you might have noted that I said,

    You want to release all the time inside your building. You need the feedback, to watch the product grow.

    Some of my clients have said, “But my customers don’t want the software that often.” That might be true.  You may have product constraints, also. If you are working on a hardware/software product, you can’t integrate the software with the hardware either until the hardware is ready or that often.

    I’m not talking about releasing the product to the customers. I’m not talking about integrating the software with the hardware. I’m talking about small, frequent, fully functional releases that help you know that your software is actually done.

    You don’t need hardening sprints. Or, if you do, you know it early. You know you have that technical debt now, not later. You can fix things when the problem is small. You see, I don’t believe in hardening sprints.

    Hardening sprints mean you are not getting to done on your features. They might be too big. Your developers are not finishing the code, so the testers can’t finish the tests. Your testers might not be automating enough. Let’s not forget architectural debt. It could be any number of things. Hardening sprints are a sign that “the software is not done.” Wouldn’t you like to know that every three or four weeks, not every ten or twelve? You could fix it when the problem is small and easier to fix.

    Here’s an example. I have a number of clients who develop software for the education market.  One of them said to me, “We can’t release all the time.”

    I said, “Sure, you can’t release the grading software in the middle of the semester. You don’t want to upset the teachers. I get that. What about the how-to-buy-books module? Can you update that module?”

    “Of course. That’s independent. We’re not sure anyone uses that in the middle of the semester anyway.”

    I was pretty sure I knew better. Teachers are always asking students to buy books. Students procrastinate. Why do you think they call it “Student syndrome”? But I decided to keep my mouth shut. Maybe I didn’t know better. The client decided to try just updating the buy-the-book module as they fixed things.

    The client cleaned up the UI and fixed irritating defects. They released internally every two weeks for about six weeks. They finally had the courage to release mid-semester. A couple of schools sent emails, asking why they waited so long to install these fixes. “Please fix the rest of these problems, as soon as you can. Please don’t wait.”

    The client had never released this often before. It scared them. It didn’t scare their customers. Their customers were quite happy. And, the customers didn’t have all the interim releases; they had the planned mini-releases that the Product Owner planned.

    My client still doesn’t release every day. They still have an internal process where they review their fixes for a couple of weeks before the fixes go live. They like that. But, they have a schedule of internal releases that is much shorter than what they used to have. They also release more often to their customers. The customers feel as if they have a “tighter” relationship with my client. Everyone is happier.

    My client no longer has big-bang external releases. They have many small internal releases. They have happier customers.

    That is what I invite you to consider.

    Release externally whenever you want. That is a business decision. Separate that business decision from your ability to release internally all the time.

    Consider moving to a continuous delivery model internally, or as close as you can get to continuous delivery internally. Now, you can decide what you release externally. That is a business decision.

    What do you need to do to your planning, your stories, your technical practices to do so?

    Categories: Blogs

    Retrospective Plan from a new ScrumMaster

    Growing Agile - Thu, 10/09/2014 - 14:00

    It’s always great as a coach when you see someone take what you have taught them and really embrace it. Rushida Hendricks is a new Scrum Master at Liberty Health. This is the retrospective plan she created for her team’s fourth retrospective.

    Sprint 4 Retrospective 791x1024 Retrospective Plan from a new ScrumMaster

    What I love about this plan is that the bulk of the time is spent in Generate Insights and Decide What to Do, the most important parts of the retro.

    She has allowed 20 minutes of buffer time in a 90 minute retro, which means no section needs to be rushed if an interesting discussion is happening.

    I love the checkin since it focussed the retro on the team and their needs. A common mistake of new teams is to think the retrospective is for the Scrum Master.

    Generate Insights follows on nicely from the previous activity, using the output from one activity as the input for the next. Again this is something that takes experience to get right.

    There is a nice mix of individual and group activities to ensure that everyone is participating. Rushida is also using technique of having people write down there thoughts (e.g. in the close) before they share them, which works well for more introverted team members.

    You can download the full plan here: Sprint 4 Retrospective Full

    Categories: Companies

    How to make wall-related decisions in Distributed Agile projects

    Agile World - Venkatesh Krishnamurthy - Thu, 10/09/2014 - 13:41

    I authored the following article for Cutter which got published today. So, it is hot out of the press.

    The subject that every distributed Agile team is questioning is the topic of setting up visual walls. Conflicts arise when purists argue in support of setting up visual boards across all locations, while the distributed teams consider it an inconvenience.

    Many companies don't realize the importance of making the right decisions related to visual walls. Typically, wall setup is left to the ScrumMaster. These companies don't realize that this "single-handed" decision could result in loss of productivity, increased stress levels, and thousands of dollars in loss due to waste.

    ====  I am recommending a principle based approach for deciding if the information needs to be displayed on Physical wall or Digital wall. ===============

    Wrong wall decisions or forcing wall decisions on a team could end up with stale walls and thousands of hours could be wasted in maintaining these walls. Be sure your organization considers the core principles during its exploration of walls.

    Since this article is available only for Cutter Members, kindly continue reading rest of article on Cutter

    image

    Categories: Blogs

    The Life of a Product Owner Proxy

    Scrum Expert - Thu, 10/09/2014 - 12:20
    Being a Product Owner (PO) Proxy is difficult. You are pulled between product managers and engineers, holding the middle ground can be a challenge. Translating technical issue to Product Management and Customer issues to Engineering is a valuable task, but sometimes it can feel like a thankless one too. This presentation shares experiences and thoughts on this challenging but not often coveted role.Video producer: http://agileprague.com/
    Categories: Communities

    Knowledge Sharing


    SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.