Jan 28, 2013

Scream! Work-in-progress is a waste, do One feature at a time

The best thing about the future is that it comes one day at a time. – Abraham Lincoln

Hypothetically, if a team is left with only Two-thousand keystrokes – it’s just a random figure, enough to convince my mental model – the toughest challenge, despite the fancy features in the Product Backlog and the Build Matrices, is to deliver value for the money. For a novice team this would look nothing but chaos, but it doesn’t when the keystrokes are the limited window of opportunity to dive in the blue ocean.

Use agile programming methods

Use agile programming methods

Doing Scrum way of Product Engineering, the Agile Diaspora of the software industry, especially in offshore and outsource teams, keeps forgetting its very basics of delivering Working Software as a Team. In simple steps, Scrum starts by breaking down a product idea into a smaller features, which is then prioritized and shipped iteratively as a team that shares the same goal. Experts from Continuous Inspection to pretty much Continuous everything have been talking about this now and then. A smart decision, even in real world, is to push many stories to the right-corner of the Scrum Board. A much smarter decision, however, is to get the top stories first, obviously, but what it is then went wrong with delivering features?

An experienced team can have their interpretation of how they should be delivering features within the sprint, as their wish. Let’s accept, passionate developers compelled to pick stories that are fancy them more. It’s their ego that is not letting go of any technically challenged task. It is the same ego that keeps them over committed on work schedules, regardless of how good or bad their time management skills are.

You worked on tasks that aren’t important

You worked on tasks that arn't important

Matured teams can wish to formulate self-organized self-governed for themselves. The catch is, when the team was struggling, it’s that cynical habit of them to volunteer for troubleshooting, stepping out their own urgent and important stories, and multi-tasking. As Stephen R. Covey nicely explains in his book First Things First, it’s not unusual to see how people move onto not important activities that appears to them as urgent. Thus the Work-In-Progress cannot indicate the actuals of the sprint since there are many people involved with too many feature stories, simultaneously. The PO, management, stakeholders, and the team too have to be patiently wait till the end of the sprint to know the remaining work since Burn Down matrices do not adapt the numbers.

XP, or rather interesting Feature Crews – What do these have for Scrum teams? A way of pairing working model to glossing over, if adopted with care. There is nothing unusual in splitting the team among smaller ministries. Perhaps, not too many and not too little but just enough to get the features move forward without being blocked half-way through. It is said, two heads is always better than one. The changing scenario in Scrum teams begins by:

  • Pairing with an experienced developer when the code is not familiar.
  • Work-in-progress stories indicate the active stories that the team is currently working.
  • Working at a pace which is currently optimum for the team.
  • Number of stories that are slipped to the next sprint is minimal, or rather declined.

For the benefit of stakeholders, clients, and those who think the time has arrived to dive into the blue ocean, after sprinting few iterations, it is a matter of terminating the current sprint and compiling the features what was in the right-corner of the Scrum Board. Despite the features that can be shipped, the ones that has been discarded can be minimized with its focus on the limited work-in-progress.

More useful resources:

Scrum Teams   Scrum   Productivity   Lazy Developer Series   XP   Feature Crews   Lean   



Permalink →

Comments

Dec 3, 2012

Do we need another wheel again?

You can be my disposable evil lackey!

We can be my disposable evil lackey

Inventing the wheel again and again doesn’t make sense! But, it sure feels awesome when you make a new one, isn’t it? Programming HTML5, CSS3, and JavaScript is in the climax of this era. There are plenty of client-side JS libraries available, for instance, jQuery UI and Kendo UI comes really handy when it comes to UI controls, but, it sounds funny when the same controls cannot do what you want, plus, minus the JS part and you end up with not so much of choices either.

Visualize! What’s with Accordions, Tabs, Menus? What do they have in common? Behavior! Which is why most implementations have unordered-list - ul tag - as the skeleton. No matter how popular is the approach, you’ll notice that it’s interesting to deal with the state of the currently selected item scenario, and it’ll get more interesting if you try it without JavaScript.

Replacing list with radio buttons

Radio buttons are quite good for Single source of Truth concept. Meaning, in a group of radio buttons, only one radio button you can mark as checked, which is why it comes very handy in this scenario. You just have to prefix a radio button on each element - tabs in this case - to obtain the state of the selected item.

https://gist.github.com/kosalanuwan/a6c518b7413af554c05a

Note the for attribute in label tag that bounds to the specified radio button, and ofcoz, nobody likes to have a bullet holes next to captions so take it off with little bit of styling.

Toggle content when clicked

It’s called General Sibling Combinator effect! Pay attention to this;

The elements represented by the two sequences share the same parent in the document tree and the element represented by the first sequence precedes (not necessarily immediately) the element represented by the second one. – w3.org

If you wonder what that means, the style is applied as long as the radio button and its corresponding content share the same parent DOM element, in this case, input and the article tags sharing same div as their parent.

https://gist.github.com/kosalanuwan/4ed5ff6ff21a110a3ef0

For this selector to work in IE8 and earlier, a <!DOCTYPE> must be declared. – w3schools.com

Toggle content is nothing but to show the content - article tag - bound to the checked radio button and to hid the rest by setting the height to zero. You could also use the visibility attribute but height is more appropriate in here.

Pragmatic use of Sibling Combinator

What can you do with it? Just change the layout the way you want, decorate with some CSS, and you get an accordion. Accordion can be multiple expandable as well. In that case, make the radio button a checkbox.

code + demo: accordion with html5, css3, and no javascript
code + demo: accordion with multiple expandable option, without javascript

Implementing an accordion is quite easy and it’s the boilerplate for the rest of the components, for instance tab control with vertical tabs. The trick is to split the captions from accordion and put it on aside, which is another reason to use the for attribute with some float:left.

code + demo: tab control with vertical tabs, with no javascript

Pay attention to the HTML layout on the vertical tabs. This can be used to demonstrate a traditional tab control with horizontal tabs, which you can simply turn into a horizontal menu with sub-menus, with minimum changes.

code + demo: horizontal menu with sub-menus, without javascript

More good resources on CSS Sibling, Label placement:

Lazy Developer Series   Interaction Design   How To   Development   HDI   No JavaScript   HTML5   CSS3   Tabs   Accordions   Menus   JSFiddle   



Permalink →

Comments

Nov 1, 2012

When the team hits lull in the sprint?

Excuse me for trying to fill a lull in the conversation

Excuse me for trying to fill a lull in the conversation

What would a scrum team do when they hits lull in the middle of a sprint? Do something small that has a value in it!

Lull is where the team manages to resolve all work items in the sprint backlog with zero bugs halfway through the sprint. You don’t see this very often!

It’s uncommon to find a lull moment for a scrum team, so, many try to get busy, occupying them leisurely. Several major avoid-if-possible things when the team hits lull in the sprint here:

a) Fixing bugs?
It could be a juicy bug, probably not logged yet, but, it’s good to investigate first, and then pass it on proper channels/discussions to identify its source, severity, and the fix required. It could be a small bug, nearby, relevant to original bug, but, it could have planned to release in a later sprint/release.

Bugs that have lesser impact on users get less priority. The fixes are pushed to later sprints/releases.

b) Cleanup some smelly code?
In my article called What’s wrong with my code, here’s what I said about smelly code;

Smelly code is a bitch. Do you think that’s because programming sucks or do you think it’s because working on other’s program sucks? For the record, not everybody sucks on programming but we don’t see good code either, as in no such thing called good code there.

As much as I hate to say; the probability of introducing more bugs in correlated code regions is quite high in this scenario. It doesn’t add any value to customer. Unless there is a really good reason to rewrite or refactor, you better not touch already tested code.

Rewriting to improve performance, scalability, adapt new components/plugins are justifiable. Still, it’s just another prioritized work item for another sprint.

c) Taking more work items?
Backlog could be prioritized with work items small in size, enough to fit in, but, bringing in more work items to the sprint can overcommit the team to an unsustainable pace. It can ruin productivity.

d) Start a new sprint?
Though work is completed or not, sprints will continue to iterate in a constant pace, without any breaks/intervals/gaps in between, but, wait a minute! Software is not built by just resources; it’s built by people, your team.

A lull moment is too valuable to waste. It’s a good opportunity for your scrum team to step out and wander around for improvements. Few experiments-to-try when the team hits lull in the sprint here:

a) Let’s go through issues!
It’s always good to inspect any mistakes/patterns behind design issues and bugs so the team can discuss what requires adapting better approaches to produce more quality product in next release. Team can also inspect process issues. It can reduce engineering waste.

As scrum always says; To improve productivity, find the blocks and remove them. Inspect and Adapt! baby.

b) Let’s write a cool plugin!
Not all tools can get what cross-disciplined teams need, so, you still need to write in-house scripts to automate check-in, build, package, and to make processes smoother, and this is where dev teams come in handy. Besides, writing cool programs is what devs are really passionate about!

c) Let’s learn new stuff!
Boring is what devs always complaining after mingling for a while with same tech and skills. It’s too valuable to miss the opportunity to learn a new technology, a skill, a new language, attend for a trainee program, or prepare for a certification.

Being a professional is not easy. It’s good to read things related to career, be up-to-date, and maintain your Expert status.

d) Let’s research!
Research is often difficult to timebox and many scrum teams neglect after their project kickoff. It sounds awesome to do minor research work such as user feasibility, localization issues, platform compatibility and so on, that can bring value to project. Studying comprehensive data and process of the product to suite test scenarios can drop bug rate. It can also wow the Pigs and Chickens.

e) Let’s write a white paper or a blog article!
Every developer must have a blog. When else your team has time to leave footprints on what they do? It’s relatively fast and a huge morale boost for the team. White papers are always good to share ideas with others and can bring some respect to the authors.

Blogs, white papers, patents give a nice touch in professional community.

f) Let’s work on pet projects!
Every developer must have at least one pet project to do trial-and-error, fantasize on new technologies, frameworks, and even components that don’t ship in your Toolbox. Try a different programming language and a tool you desire.

Social coding is the new open source community. Github is good place to start wander around.

g) Let’s do some initiatives!
Team could be performing well and assembled with smarter people, but, initiative programs can further amplify their creativity and leadership skills. It’s a really good chance to be part of something bigger and it can bring some recognition to the initiator and the team.

In my current company, certain initiative programs were organized to cater even broader audience. Colombo Code Camp, SL Bar Camp, and the very latest program Interns’ Summit were among them.

h) Let’s have lean coffee!
No matter how many coffee breaks your team had, nothing beats Lean Coffee. It’s a good time to step out and think about other than work items. Share interests on career planning, work-life-balance, 7 habits, image building, time management, or even gifts for girlfriend, in a nutshell. Helps shake of the dull feeling and rethink.

Lean Coffee is a Kanban game to play during coffee time. All you need is sticky notes, marker pens, a board with 3 columns: Topics, In progress, and Done; and a pile of topics to chat.

More good resources on Agile/Scrum:

Scrum   Agile   Lean Coffee   Productivity   Sprints   Scrum Teams   Feature Crews   Distributed Scrum   Lull   



Permalink →

Comments