Neville's Random Thoughts

How about a simpler Functional language? Maybe AppIgnite?

2010-06-07T12:22:00.000-07:00

I think nearly every programmer has written a game. Why? Because dev's tend to be gamers...they are "game domain experts." What a Dev knows is easiest for them to program. Like my friend, who released a time tracker app, he was a contract programmer and he needed a time tracking solution so he wrote it and sold it to others. It was written because it was in his head.

Think of all the niche apps out there that could be written, but will never be written because the "domain expert" is not a programmer. Ideally, there would be a "functional" language intuitive enough for anyone to get started, right-out-of-the-box.

And when I say "functional" I'm not referring to the myriad of expressive languages that have emerged, I envision something visual, less syntactic, but still extensible, so that the idea-man could mock up a working app and possibly team-up with others to extend the solution.

I'm really excited to hear more about AppIgnite. Although it's not yet ready for prime-time I think Jason is on the right track. I learned about AppIngine on Techzing (an outstanding Podacast, where Jason and Justin share everything of interest from the world of entrepreneurial dev's). They both have home-grown commercial apps and share their daily thoughts and experiences through the Podcast.

I know the dream of a "programmer-less-programming-language" has come and gone in many forms, but listening to Jason expound on AppIgnite's design I'm really looking forward to getting my hands on it. This has the potential to be a productivity "game-changer" for everybody who has an idea for an app, but nowhere to start.

What If Congress Adopted the Agile Manifesto?

2010-02-28T14:10:00.001-08:00

I wish Congress was full of Agile Practitioners (Poppendieck for Senate!). Thinking about this I wondered how the process of passing Heath Care would look when judged through the lens of the Agile Manifesto. Below is my retrospective of HR3200.

The Agile Legislative Manifesto:

1) Our highest priority is to satisfy the customer through early and continuous delivery of valuable legislation.
...9 months and 2074 pages, ummm I don't think so...

2) Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
...Congress did implement some "competitve advantages" for customers like Louisiana ($100M in exemptions), California ($300M in Medicare payments), AARP received $18M in stimulus money and the Unions got an exemption for "Cadillac" health plans. However these "advantages" inure to the benefit of constituencies, some stakeholders may disagree.

3) Deliver working legislation frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
...Fail

4) All Parties must work together daily throughout the project.
...Fail again, 'nuff said

5) Build legislation around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
...There have certainly been a lot of "motivated individuals" working on this but not a lot of "trust" and "support."

6) The most efficient and effective method of conveying information to and within a legislative team is face-to-face conversation.
...There appear to have been many closed-door "face-to-face conversations," unfortunately many essential stakeholders were excluded, the entire process could have benefited with some transparency, courtesy of C-span.

7) Working legislation is the primary measure of progress.
...No measurable velocity yet.

8) Agile processes promote sustainable development of legislation. The sponsors, legislators, and users should be able to maintain a constant pace indefinitely.
...The political machine has chewed up and spit out everybody involved. "Sustainable development" has yet to be achieved.

9) Continuous attention to legislative excellence and good design enhances agility.
...Maybe this can be included in a future iteration
.
10) Simplicity--the art of maximizing the amount of work not done--is essential.
...I think Congress skipped this step. Oh well, it was the only "essential" step.

11) The best architectures, requirements, and designs emerge from self-organizing teams.
...All teams were "self-organized" unfortunately they organized down party lines.

12) At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
...Mid-term elections could make for an interesting retrospective.

Pair Programming in an Office Cubicle

2009-10-03T16:23:00.000-07:00

I'm really impressed with development teams that pair program, it alleviates a lot of development pressures. Companies like Hashrocket are leaders in pairing practices, In his post Obie describes what's "required" to equip your pair programming environment.

Yeah, all that extra equipment is nice, but what if your team is locked into a typical office cube setup?

Is it possible to comfortably pair in cubicles?
What if you can't afford wide desks and a bunch of huge monitors?
Must pairs be co-located?
Can a typical office setup accommodate pair programming?

Check out this photo of my most excellent team-mates arranged in typical office cube fashion.

I like these cubes, the low walls make it easy for us to communicate.

Yup, even cubes can be can be conducive to communication. Meet my cube neighbor Rach. See how easy it is for us to converse? So, let's do some pair programming in the cube!

Oh, I hear ya... "how can you share a monitor across a cube?" MS Team Viewer to the rescue! Team Viewer is Microsoft's screen sharing app, it's easy to use, free to try, secure and IP based. Team Viewer faithfully reproduces your screen on your pair's monitor, plus it allows your pair to drive from where they sit with their mouse and keyboard.

Now, you're both viewing the same image and you're conversing face to face, what else do you need?

Ok, I hear ya..."how can my pair see me pointing at their egregious coding error on the screen?" ZoomIt. This is a free utility from TechNet that turns your cursor into a pen, so you can draw on your screen, mark-up and highlight any area on your screen and wipe it clean when you're done

Pairing on two machines is way better than one. Suppose you need to IM a quick question to your stakeholder or check on the progress of the build; your pair can keep stubbing out the new class while you Google up the crazy syntax on that overloaded method. This setup creates the best of both worlds.

Speaking of the world; add a headset, webcam, skype and now you're pairing anywhere...with anyone! So, still think you need a 42" plasma and dual keyboards, forget 'em. Now, go forth and pair.

Value - in a nut shell

2009-04-10T11:15:00.000-07:00

A constant flow of new ideas is vital to any growing business.

But what makes an idea great? Which ideas get the most attention? All great ideas take into account the following 3 important factors

Resources: What resources (time, money, people) are needed to implement this idea?

Risk: What could potentially be lost? What areas of the business become vulnerable? How is the business exposed?

Reward: What is gained by implementing this idea? How does the business benefit?

The perfect idea maximizes Reward while minimizing Risk and Resources. Everybody has some good ideas and ideas can come in every shape and size, but the real key to success is to capitalize on Reward while limiting Resources and Risk.

Especially during these lean times low Resource and high Reward ideas are more valuable than ever.

"Strategery!"

2008-10-18T18:30:00.000-07:00

Time for an introspective look...

Being vaguely aware of the difference between strategy and tactics I decided to learn more. And in learning more, it's clear that I'm a strategist. Further more, I'm not much of a tactician, and I think it's because I attempt to apply strategy to tactics. Let me explain:

By my nature I'm an observer.

I'm always observing,

In my observations I'm looking for patterns,

Then matching observed patterns to previously discovered pattern,

And using those patterns to determine possible outcomes.

...sounds like typical strategy stuff.

However, observation is a passive activity and successful tactics require action. I keep wanting to apply strategy to tactics and it doesn't work. What's needed to apply successful tactics is execution.

The old Nike commercial says; "Just do it." By contrast my commercial would be "Just analyze it."

Here at Devlink in Nashville

2008-08-22T12:54:00.000-07:00

So far the best session has been the informal experts panel that was held during lunch. Some gems came from the guys on the panel.

After 33 years of changing technology knowing a methodology and language are secondary. More valuable skills are are;

the ability to solve your problems...agiley
understanding business domain problems and mapping them to the code (ie: developers are no longer coding in a silo, you've got to understand the solutions's "what" and "why")
(not really a skill, but I loved this...) subersively sneak Agile principles into an organization (a great story about a continuous integration server hidden under a developers desk)

Really cool stuff.

The simplest measure of value

2008-05-29T16:22:00.001-07:00

Jack also brought back this very simple equation from PO Certification.

Business value = Business visibility

Use 'point' estimations only to a certain 'point'

2008-05-29T16:22:00.000-07:00

My buddy Jack went to Mike Cohn's Product Owner Certification class. He returned with this great analogy providing the context for "point" estimation and "hour" estimation.

If 2 runners of varying skill are asked to estimate the task of running a fixed distance; the faster runner might say, "that looks like a 15 minute run," where as a lesser runner might say, "no, that's a 30 minute run."

In making disparate time estimates (of the same task) the runners have demonstrated the value of point estimation. Ask the runners to measure the task in terms of points (lets say 1 point equals 1 mile). Now the runners can agree "Yes, that looks like about 2 points." Using points they reach consensus and provide the PO with a sufficiently high level estimate to assist in prioritization and pre-planning.

However, when it comes to sprint planning, start moving from points to hours (this is new from Mike). Like in the case of our runners, the hour estimate is useful in helping the team plan thier work for the sprint. If one runner is faster than another this may help the team members to adopt the tasks they best suited for.

Adaptive Sampling, you're doing it and don't even know it.

2008-01-21T20:14:00.000-08:00

Alistair's article of adaptive sampling make a good point about quality not needing to be uniform:

"... First of all requirements statements aren't requirements, they are only placeholder tokens for [need-solution] pairs. Secondly, the system doesn't have a single quality requirement, the quality characteristics vary by [need-solution] pairs. We can save time and money on the project by examing each "requirement" (or wish, or user story, or backlog item) individually, and working out what the appropriate level of effort will be needed at that one spot. We can save time and money in that endeavor by using [this] adaptive sampling idea and breaking the work into areas, those with similar quality needs..."

Stretch Tasks

2008-01-17T17:43:00.000-08:00

In Kelly Waters' "All About Agile" blog Kelly says: "Include a bit more than you think can be achieved. It's important to prepare more items during planning in case the team finishes early. These items can be clearly identified as stretch tasks and the Product Owner should not expect them to be completed. These are the things you will only do if the Sprint goes better than you expected."

A great quote

2008-01-04T16:52:00.001-08:00

I found this valuable quote in the Introduction to the Eclipse PPT. It's by Alfred North Whitehead, a 19th Century British mathematician, logician and philosopher.

"...by relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and in effect, increases the mental power of the race."

Agilists at Graffiti labs

2008-01-04T16:52:00.000-08:00

Here Bre Pettis hosts Michael from Graffiti Reasearch Labs, Vienna. Michael expands on a traditional Agile mantra saying "...release early, often and with 'rad' music..."

No more "done"

2008-01-04T14:02:00.001-08:00

I dislike the word "done" because the defenition can be so subjective. For instance, my idea of "done" may not be your idea of "done." Instead of asking "...is it done?" I would prefer we ask "...does it perform?"

Not more info, but the right info

2007-12-30T18:56:00.000-08:00

Here some dude says this: "This takes me back to Herbert Simon’s stupid idea that all we need is more information. What? Now, he’s dead we have all the information we could possibly get our hands on and the world is no better off! In fact, the more information we get the worse things become."

Fascinating...

The shortest distance

2007-12-16T20:44:00.000-08:00

Is this totally Lean? You don't know what "you don't know" until you know it. So minimize your reliance on guess work. Use Occam's Razor and push forward. Do something, measure it, revise your model based on the new metrics, rinse and repeat. Keep speculation at a minimum.

Pragmatic Webinar

2007-12-12T20:07:00.000-08:00

Steve Johnson presented a webinar on the Pragmatic Marketing site. It was worth the watch for quotes like:

"The real role of an Agile Project Manager is to force the project to leave the building despite the company's best efforts to prevent it."

And "I don't accept the premise of your question."

And this interesting formula: "Evidence * Impact = Priority"

More thoughts on valuation

2007-12-08T19:15:00.001-08:00

Somewhere on the Tyner Blain blog it says this:
"Financial benefit is what we have to base our decisions on - both hard ROI and soft ROI data. We can measure cost data, and even forecast it - taking into account both fixed and variable costs. But if we use the wrong cost allocation strategy, we will make suboptimal decisions. The success of a requirement is based upon the ratio of value to costs."

Many streams of thought here...one conclusion is this; bad numbers are worse than no numbers. Maybe during the retro we should look back at the predictions and see how accurate we were, then apply that same percentage of correctness to future considerations.

Deep thoughts (better than Jack Handy)

2007-12-08T19:15:00.000-08:00

This is very deep and might be cool (if it can be transliterated from "theoretical" to "actionable"). Read this link.

Contained is this quote; "Remember a rule of system thinking is to understand the whole in favour of the parts. So look at the situation and ask your self how are the different smaller level wholes related to make the bigger level whole."

BA's in the Agile process

2007-12-07T16:54:00.000-08:00

This dude here is reasoning out the role of a BA in Agile development.

His main point are these;
Developers can't elicit requirements. I agree, not because they can't, but developers should be busy developing. I'm not advocating insulating the developers from the users, but provide them the opportunity to productively develop without the added burden of trying to elicit useful information from the requestor...unless they want to.

Stakeholders can't model and document their own requirements. This is true. If a requestor is not familiar with creating a "user story," or expressing "conditions of acceptance," etc. Then someone (in the BA role) needs to stand in the gap and complete these components of requirements gathering process.

You need analysis experts. I don't agree with this. The developers should be able to analyze the requirements to propose a technical solution. The key word being "should." But it seems as if they push-back, they just want to "know what to code." Not "figure out what to code." What am I missing? I'd like to have another perspectives.

Getting value faster

2007-12-04T14:26:00.000-08:00

Here Tyner Blain blog says this "...no one is promoting that we maximize value - they (and we) have been promoting that we do the most valuable stuff first. Doing the most valuable things first does not result in getting value the fastest"

I think this is the perspective we need to adopt for project valuation and why we should attempt to compare effort to value.

The rest of this article is excellent explanation of "velocity points." Better than the nebulous explanations that are dished out thru most Agile training

The Most Valuable

2007-12-04T14:18:00.000-08:00

This is the introduction of the "grid" concept of prioritization. I found it here and here is part 2. Both articles contain lot's of other useful links.

The article says "If you're in a situation where prioritisation is straightforward and you have a single decisive product owner, you probably need to read no further."

This is the problem...when prioritizing multiple opportunities between several departments and managing stakeholder interests there needs to be an objective system. My goal is to avoid arbitrary decisions.

This is the best method I've seen because it's simple and visual.

Thoughts on Kano

2007-12-03T15:18:00.006-08:00

Kano appears useless for prioritization, but might be useful for evaluating user satisfaction once the product is completed. Could be useful in a retrospective.

Here's an flash tutorial

Small iterations

2007-12-03T15:18:00.004-08:00

In 10 Successful Criteria For Software Development number "6" under "Success Criteria" is "Smaller Project Milestones." Smaller iterations are being realized as a best development practise outside of Agile.

Prioritization concepts

2007-12-03T15:18:00.001-08:00

Read this it's really good. The blog entry starts by saying "The less we know about our client’s business, the more the requirements appear to be equivalent." All the more reason to aggressively depose stakeholders for specific value.

Although this article is about prioritizing features, it holds a lot of truth about prioritizing for any project. Including validating ROI over preference (let's keep it objective).

Visual cues

2007-12-03T15:18:00.000-08:00

For visual representation chart value items in color.

Red (hot) to blue (cold) depending on executive support.

Or increase size if it meets strategic goals.

The difference between TDD and FIT

2007-12-03T14:18:00.000-08:00

Here James Shore makes a great differentiation below:

"...Fit examples are not unit tests. Fit examples are just that: examples of a business rule in action, from a business perspective. In TDD, I write tests for every line of code that can possibly break. In my Fit examples, I try to talk about every possible business case. That's a bigger net than TDD, and without TDD, my code wasn't well tested."

James calls Fit "Storytest-driven development" or "STDD" (despite the stigma) I think it sounds like a super Agile concept. So is this where the "user terms of acceptance" from the nebulous "user story" get converted into arguments in the FitNesse wiki? This is a good picture of executable documentation. (Now this is where imagination is needed) How can all the varied and complex features of a solution be represented in a Fit test?

How can this be re-paid?

2007-12-03T14:06:00.000-08:00

According to this article, AES improperly exploited a subsidy program to collect $34 million from the government. How can they payback that amount without it drastically impacting their business?

Idea origination and ownership

2007-12-01T17:03:00.010-08:00

Introducing the Market Requirements Document and the Product Requirements Document

This is an interesting commentary of solution scope from the Tynerblain blog. At Ed, the business unit probably creates the MRD (intellectually if not in writing) both these and is likely to include S&S or engineering in the process. From this article it doesn't sound like the norm, but I'm not sure Systems and Solutions or engineering has the resources to assist in these decisions.

Maybe the answer is here

Agile's biggest weakness...isn't

2007-12-01T17:03:00.008-08:00

Tyner Blain blog lists these items being "Agile’s biggest weakness[es]." I don't know if he's serious or not, put none of these seem like legitimate complaints.

He says Agelists "minimize forecasting." I believe that forecasting is not minimized it's optimized. You forecast until you have as much of forecast as you need to move forward. Is there something wrong with that? You don't know what you don't know until you know it, so get there as soon as possible.

Here's the list from the Tyner Blain blog;
1. Most companies today, when they commit to a million dollar project, want to know what they get for their money. - The purpose of agile is fail faster and defer commitment (until the last responsible moment). Spend some money to remove some doubt. Spend some more money to remove more doubt. With each iteration you're getting more "committed" and eliminating the big doubts up front. Always gaining more assurance of success without (over) committing resources. Lean, right?

2. They want to know when they get it too. - Don't we all, but who can say? And how do you know they're right? You don't know without metrics. So do something (complete a user story), see how long it took and you've determined velocity. Now multiply that velocity against the rest of the stories, not only did you get something done, but you've got a real metric.

3. ...they want to know before they sign the check. - That's the wrong perspective, if you're signing a single check for a project then you're over committing. Agile to the rescue - pay as you go, you're never over committed.

4. The less planning you do at the beginning of a project, the less you know about the end of the project. If you believe Occams Razor then the simplest decision is the right one. Too much planning is futile since you don't know what you don't know until you get there. Pretending that everything is (accurately) knowable is folly. Determine the next step, execute and then re-evaluate. Have a loose plan, but don't make it your constraint. Stop going forward when it's no longer fruitful, find a new approach or let it die...fail faster.

5. This is hard for non-Agile companies (or executives) to swallow. No it's not, it's simple to explain and painless to buy. "Hi Mr. Stakeholder, we are only gonna spend what needs to be spent." This does not preclude a budget, it only precludes wasting a lot of time on pretending to know how much a project is going to cost.

6. By minimizing the upfront planning, Agile teams minimize their ability to forecast the pending results. Wrong, agile teams minimize there ability to make flawed decisions based on overly confident forecasts.

I'm really glad that the Tyner Blain blog stated these "perceived" Agile weaknesses in such a specific way. It makes it much easier to refute them. Most Post-Agelist or Anti-Agelists use some vague metaphor, which doesn't really address the project conditions.

Refuting Lean?

2007-12-01T17:03:00.006-08:00

How come most bloggers trying to refute Lean concepts and Agile methodologies sound like Durwood Fincher?

Requirements gathering

2007-12-01T17:03:00.005-08:00

Some dude says this here

"If you believe that customers are responsible for defining their requirements, you will primarily employ interviewing and 'elicitation' techniques to obtain requirements. The definition of elicit is 'to draw or bring out or forth; educe; evoke.' The customer often perceives this as 'extraction' or even 'extrusion.' Using this method, you are at your customers' mercy--you know only what they tell you. Requirements will almost certainly be incomplete. Even if customers appear unable to define their requirements, you may believe that they are not only able to do so, but that they are responsible for doing so. You may believe that the correct elicitation tools and techniques will achieve success."

It sounds like he's saying customer's don't know what they want. I agree that is frequently the case. Showing them "concepts" can help them see what a potential solution looks like.

Fail Faster

2007-12-01T17:03:00.004-08:00

“I have not failed seven hundred times. I have not failed once. I have succeeded in proving that those seven hundred ways will not work. When I have eliminated the ways that will not work, I will find the way that will work.” - Thomas Edison

Don't forget to leave room for the failures and leverage the development process so you fail faster

Start quick fail faster (be lean)

2007-12-01T17:03:00.003-08:00

Kent Beck says this (Tyner Blain blog):
"...customer’s don’t know what they want, we should start building stuff right away, with the expectation that by seeing tangible results (good or bad), they will have epiphanies about what they really want. This approach treats requirement extraction as an emergent process, like strip-mining. With each new layer of mining, we unearth a new set of hidden requirements."

Build first ask questions later goes too far. I think we can prototype (hi or lo-fi) and show customers a vision of what they've requested. From that we can help them discern what they need. This makes me recall a session from Agile 2007, when we demonstrated functionality by each person playing a different role (replicating the technology) and users interacted with the interface. It made for fast process adjustment to user feedback.

Two soft concepts

2007-12-01T17:03:00.002-08:00

This may be an interesting article on ROI. ROI is both hard and soft. For an automation hard costs could be a savings of man hours...very calculable and very predictable. Soft ROI numbers should be discounted 60% to 90% according to Tom Pisello.

I jacked this from the Tyner Blain blog: It's where another soft concept is introduced, the concept of utility:
"Agile software proponent Kent Beck argues that people don’t know what they want when you ask them. There may be some scientific support for his argument based on some research cited by Barry Schwartz in The Paradox of Choice: Why More is Less. Schwartz references psychologist Daniel Kahneman’s studies of how people remember events, in an explanation of how people measure and assess utility. To sum up, here’s the flow of events: A person has an experience, and recognizes some satisfaction from it. This is known as experienced utility. This is the function that economists reference when defining the indifference curve. When remembering the event later, a person will remember incorrectly. Their memory of their level of satisfaction is their remembered utility. The problem is that the remembered utility never precisely matches the experienced utility. This poses an interesting problem. Even if we find people who have experienced exactly what we’re trying to analyze, they will be unable to correctly tell us how much satisfaction they derived in the past."

Here's the Tyner Blain blog conclusion:
"The value of a requirement or feature is a function of user satisfaction and the financial benefit of having that requirement implemented. The user satisfaction can not be quantified in advance because we have no framework for reliably predicting satisfaction - even based on past experiences. "

That is very interesting, as much as user's demand certain features without being able to provide a cost justification for their demands.

Project Management Gems

2007-11-30T17:03:00.000-08:00

Tyner Blaine has a blog full of great Project Management info. Most of it from an Agile perspective. Check it out. http://tynerblain.com/blog