Posted in Agile Theory, Methodology

How to become an Agile Developer in 10 Steps

#1, Pair programming
– It’s nice start then trying pair salary negotiations, pair coffee sugaring, and pair shoe tying.

#2, Unit Testing
– Backing your code with unit tests make it less prone to errors. To be on the safe side, however, it’s highly recommended to also unit test your unit tests with some unit tests.

#3, Code Review
Practice the art of reviews as often as possible.

#4, Keep it simple
Refuse to write complicated code: tell your customer that his ecommerce system will only handle payments by cash.

#5. Design patterns
The use of design patterns can greatly improve your code quality. Invent your own ones and encourage your team to use them as often as possible. Who wouldn’t love the “pink bunny” pattern?.

#6, Coding conventions
– Make your coding standards more enjoyable by handing out a printed version to each team member. Personalize each copy by coloring the sides of the pages.

#7, Useful Error Messages
Avoid inexpressive error messages like “error code 148″. Instead, add helful status information and make them meaningful.

#8, Learn a new language every year
– A good programmer is expected to learn a new language every year. When asked which language you’re currently learning, warmly touch your colleagues’s hand and tell him it’s the ” language of love”.

#9, Enhance your scrum/ kanban road
On a standard Scrum or Kanban board, tasks are moved from “todo” to ” in progress” to “Done”.

#10, Consisten Toolchain
If a team agrees to a common set of tools, everybody on the team should adhere to the rules. Kindly but firmly remind your CEO that no one else use Excel on the team – and offer to show him how to do his ” number-knick-knack” with Eclipse.

Agile developer, Kanban, Scrum board

Advertisements
Posted in Agile Theory, Methodology

Agile Development | Are You Ready for New Smarter Model?

Many companies are embracing Agile Software Development as an effective way to increase business value, enhance productivity and boost employee morale. However, each company has its own challenges when they adopt Agile. Therefore, the question “Are we ready to Agile Development” rises. In term of project management, the answer for that question refers to this following checklist, which includes issues to be considered before starting Agile adoption.

Agile dvelopment, Agile method
Ready to adapt to Agile Development Method

1. Is management’s support available?

In Agile development projects, junior technical staff needs support from both middle and top management. While the former is necessary for every development step, the latter plays its role when roadblocks appear in a development process. If that support is not available, the project is not likely to be successful.

2. Is your team provided with proper training?

It is necessary for your team members, managers, and other ones who also involved in Agile development project to be provided with training courses. The first one to be recommended is the Certified ScrumMaster (CSM), conducted by a Scrum Alliance Certified Scrum Trainer. Another course is the Certified Scrum Product Owner training that helps product owners to sharpen their skills. Together with official training courses, your Agile team should be encouraged to have further studies in a group. This plan may be conducted before, after and even during courses. The study groups should meet periodically to discuss issues of Agile development. If you skip this method of studying, your team will lose a chance to understand the new practices and may face difficulties when adopting it to the realistic environment.

3. Was your Product Owners trained?

Product owners are those ones who connect the end customers, multi-level managers, and developers. A good product owner must have skills like good communication to customers as well as the development team and stakeholders, ability to maximize ROI, and also awesome performance in practices. Be sure to have well-trained product owners to bring your Agile adoption the big wins. And as mentioned above, the most appropriate course to train product owners is the Certified Scrum Product Owner.

4. Do you have enough space?

It is essential that all of your Agile team members maintain face-to-face communication. If each one of them sits in a separate place and only has virtual meetings, their working efficiency will decrease. Besides, don’t forget to create space that allows informal discussion between them, where they can use boards, chalks and flip charts freely.

5. Have you made the support team on board?

Ok, you trained the team adopting Scrum. And what about the support teams? Do they include database administratorsystem administrator, or the configuration manager?  Do they update information about the Scrum teams like their constraints and limitations? The advice is to ask specialists from different departments to join the scrum team, as either consultants or full-time members of the team.

Posted in Agile Theory, Testing

Agile Adoption Mistakes And How To Avoid It

Agile Software Development is a set of software development methodologies based on iterative development, where requirements and solutions evolve via collaboration between self-organizing and cross-functional teams. Agile focuses on simple code, regular testing and early delivery.

Agile adoption for project management is a growing trend in the field of software development. Businesses who adopt Agile methodology want to be flexible. They want new products, services without waiting for months or even years and to get benefits of faster delivery and higher quality.

Agile

An illustration of Agile model

However, Agile adoption does not always go well. We have collected some common mistakes that you could probably make during the implementation. Hope this approach will help you avoid potential Agile failure and succeed quickly.

Discipline undervalued in Agile

discipline-is-the-bridge-between-jim-rohn

Although Agile is based largely on flexibility, it actually requires a firm discipline to work out. A lack of discipline, which can be derived from misinterpretation or deviation from the planned framework, can be the main cause of failure in Agile adoption.

Agile underlines the importance of discipline because a project is managed strictly from planning to launching, with stakeholders’ review and feedback provided at every step of the way. Therefore it is advisable to have a close team collaboration as well as proper plans. Everything should be tracked meticulously and finished within predetermined time and constraints. That is to say, a plan should be followed to the minute and nothing is omitted.

One process is enough

It is easy for Scrum to be incorrectly regarded as the definition of agility in spite of the fact that Scrum is just one approach to Agile. Scrum is unquestionably powerful, but that is not sufficient enough for Agile adoption.

The use of Scrum only focuses on how to plan and execute a project in short sprints and adapt to feedback and it can be wrongly perceived that all problems can be solved by Scrum. If you ask why it is because Scrum reveals nothing about technical discipline or how developers should work.

Many business teams adopt Scrum in the absence of the technical practices that are required to deliver new production. It is highly recommended that Scrum should be adopted in tight companion with other techniques, such as Extreme Programming (XP).

 Lacking feedback from customers

Collect-Customer-Feedback-for-Marketing

Customer feedback is a crucial factor for any type of business

Whether your product makes sense or not is totally decided by customers as well as the end users. You can not build a satisfactory product without a comprehensive understanding of the customers’ wishes. It is a normal practice that market analysts is the proxy of customers, however, they can not adequately represent customers due to their lack of involvement in the user community.

In fact, customers should be regarded as a member of the product development team and involved in the very early stage of the project. Along with that, customer feed backs should be collected within a reasonable time for product revising. Proper customer collaboration is difficult but well worth the effort. In the end, this is what “Customer collaboration over contract negotiation” (Agile Manifesto) is about.

Poor Testing  

Testing is obviously an indispensable factor that ensures the quality of any product. Product owner shouldn’t accept a product until he knows it has met all the criteria formulated by the product development team, and this can only be done by testing. If you think testing is the last thing to be conducted, you are wrong.

Quite the contrary, testing that is similar to data creation, environment setup must be addressed at the beginning stage of the project. This is to make sure the quality of incremental delivery meets up the team’s expectation. However, testing usually confronts some obstacles: taking on a legacy application with no existing test suites, lack of tools for application, lack of knowledge and so on. When the products get complicated, manual and automated testing methods should be combined to deliver best performance.

Fail to create Cross-Functional Team   The term “cross-functional team” is used to describe a team made up of members with different functional expertise. For Agile adoption, teams with entirely separate functions can cause confusion and miscommunication leading to confliction while working. For example, instead of an IOS team, an Android team and a Test team totally independent from one another, you should create a team that includes members from all of 3 teams above.

This is mostly because Agile involve continuous iteration between team members to facilitate synchronization, therefore it would be much wiser if all the departmental boundaries are eliminated. Effective Agile leaders should create environments where knowledge is shared and skills are transferred.

The term “cross-functional team” is used to describe a team made up of members with different functional expertise. For Agile adoption, teams with entirely separate functions can cause confusion and miscommunication leading to confliction while working.

For example, instead of an IOS team, an Android team and a Test team totally independent from one another, you should create a team that includes members from all of 3 teams above. This is mostly because Agile involves­­ continuous iteration between team members to facilitate synchronization, therefore it would be much wiser if all the departmental boundaries are eliminated. Effective Agile leaders should create environments where knowledge is shared and skills are transferred.

Lack of preparation for Agile transfer  

It is quite ill-considered to implement Agile when your business is not ready. A good preparation for Agile is a combination of various factors. It could be the team members’ willingness to adopt changes, sufficient education and training or infrastructure. As a matter-of-fact, you can not expect a smoothly-ran process with tight time frame and inexperienced team members.

You should give your team necessary time and proper training to get ready for the organizational and cultural changes that Agile may bring to your company. In addition, the test for infrastructure should not be skipped and the Agile Manifesto and principles should be well-educated as well.

Poor communicationtttrtet

Communication plays a fundamental role for success in any organisation. Bad communication can cause conflicts among members and failure, especially when it comes to Agile methodology in which team members have to be ready to welcome changes anytime, even at the final stage of development.

Of all communication channels, face-to-face meeting remains the most effective one for the reason that visions and insights will be hard to be shared and educated without physical conversation. Beside this, it’s much easier to convey ideas directly on a whiteboard than explain them in detailed documents. Face-to-face is the most preferred type of communication, decisions can be made quickly and delay in further planning can be avoided, followed by video conference and phone conversation. ­If team members are working at the same physical location, then a face-to-face conversation is the best way to go.  Otherwise, video chat would be good.

Posted in Agile Theory, project management

Using GANTT Chart for Agile Project Management?

Okay, so I am at a bit of an impasse. Problem is, I see value is the Agile approach but I also see the need for something tangible to pass around the conference table. Something like a GANTT chart. I hate GANTT charts. They are one of those things that are too easy to make in a meaningless way that satisfies 90 percent of your stakeholders, but to satisfy the other 10 percent, you have to do stuff I dont think can be done (like, tell the future… and if I could I would not be writing this blog… I would be living off of lottery money and dictating the blog entry to someone).

I am not talking about GANTT charts that show blocks of development or releases or sprints. I am talking about the ones that show development tasks and dependencies and draw a nice line from the beginning to the end. David Christiansen says:

Gantt charts look cool. The ones I can make using MS-Project show task names, durations, assigned resources and milestones. All in color…in whatever fonts and fill patterns I want to use. In my experience, few things about a project proposal impress people so completely as a really nice-looking Gantt chart. Sad, but true.

Gantt-Chart-Agile-Project-Management-Template

ASSUMING you have adopted some flavor of Agile, you could of course produce these charts with a lot of wiggle room by organizing them in blocks that are understood to be malleable. However, this is not what a GANTT chart is supposed to be. At least, not classically. I am all for breaking new ground, but the 10 percent I mentioned before will be of two types:

  1. Where is the detail?
  2. Why are you making GANTT charts?

In case (1), they will also want to know “how much and when”. In case (2), they will want to know how much and when but understand you are not building a shed with supplies from Home Depot.

You will have to read what Ambler says about GANTT charts in this cached page, but to save you the trouble, he came to find they are regarded as the least valuable project asset.

I am a fan of educating Clients. Agile works, although for me it can be a bit cowboyish without a good leader on the team. Accordingly, I try to be that leader and explain THE PROCESS without sounding condescending, preachy, or singing. I tend to break into song when discussing THE PROCESS. It is majestic, afterall.

Recently, I learned a nice lesson, again (and this time it will stick, truly). Education is great, but among the people you are educating needs to be the person who sits at the conference table waiting to flip out when what may be perceived as ambiguities cost money. It is not even education, now that I think about it. It is more explanation. So, THE EXPLANATION needs to reach the right ears and mind. THE EXPLANATION makes sense. THE EXPLANATION is no good if it is on some random PM’s notebook and the CFO says, “I need to know when this project is going live and how much it is going to cost by end of day! Why don’t you know this? And dont give me that EXPLANATION!”

So again, this stuff all starts with people, not technology, and not THE PROCESS. It might not always be easy to do, because the people at the conference table are often busy, but you really need to reach them, even if indirectly.

GANTT charts are also BRUF and detailed specifications for System features that are a glimmer in someone’s eye. Now, maybe BRUF is bunk, but RUP, or better, what has been termed GRIT, has value. Even if you are going into a cave and know you dont know which way it will twist or turn, you bring a flashlight and good boots (I guess… I dont know much about spelunking).

The idea of GRIT is that an integral part of delivering great software is delivering a great requirements model. Rather than trying to completely document the requirements in one big effort early on, the GRIT approach looks at modeling as an iterative process that runs in parallel, but slightly ahead of, the agile development iterations. Early in the project the requirements are typically not well understood at any level of detail but the business objectives should be clear. As the project proceeds through the initial iterations the high level requirements should tie directly to achieving the business objectives. Each subsequent iteration should add to the model, adding detail and precision to the requirements, ‘just in time’ for development. The end result, along with great working software, is a great requirements model.

Posted in Agile Theory

What is the important of Agile Method

It is true that within Agile method you have the notion of being free of a set method and allowing the team to decide. I have heard all the arguments. Some say the team will not decide. Some say it does not work. Some say it works under certain conditions. Some say it works but only if the organization is ready. Scrum, by being a formal methodology, automatically negates what is at the heart of the Agile Manifesto and the Agile Manifesto is regarded as a kind of 10 Commandments of Agile Development but the truth is something altogether different.

We did Agile development before it was called Agile development. My coining a phrase, you create an entity (real or not – you have heard of a Unicorn, no?) and by setting forth a method by which to accomplish the goals in mind such as Scrum does you in no way break any tenets.

Agile is not unique to software. Nor is lean, Kanban, or any of the new buzzwords. They are buzzwords. They make enough money and generate enough revenue that PMI is starting to incorporate Agile methods in their PMBOK.

A bunch of guys in a cabin in the woods is not necessary in this day and age and only serves to add to the mystique behind the Agile Manifesto. As far as I am concerned, people who write Manifestos in the woods are suspicious and up to something. Not all of them are planning on blowing something up. Some are just meeting so there will be no distractions. Yeah. Because it requires complete concentration to chase a Unicorn. You cannot do it head on, after all.

I hate to say it, and I will hear about it, but Scrumban and all the over-intellectualization of what amounts to getting work done as a team is a symptom of big brains without enough to do. Or, and equally as valid, are those big brains who see the ability to make money off of the latest fad. It is nothing new, but the buzzwords are. There was always a brownie with less calories. It was not called a Light Brownie until someone marketed towards people who wanted a less fattening brownie. And that is all it is. Less fattening.

I have wondered a bit about why this bothers me so much. In a world that does not seem to reward honesty, why would I insist on calling like I see it? Saying that I care sounds and even resonates a bit hollow because I really cannot care about you if I do not know you.

I guess it boils down to a disdain for bullies. People throw words like punches and get all bent out of shape and worked up because of something as idiotic as what “done” means. Have we forgotten that everything is in context and everything has eyes upon it, therefore perspective, and that there is no judge without an opinion?

Then there are those who think it really is important to define what done is aside from any actually physical project. I will tell you what it is: an idea. A Unicorn.

Get your work done. Inform yourself. Learn. Be wrong once in awhile. Be honest even if it hurts. Scrum, Kanban, Lean, and the like are all meant to take your attention away from what they entail and that is delivering software. I did not say good software. There is no such thing. There is software that does what it is supposed to for some people and not others and there is software that plan stinks because nobody likes it.

Do your best and keep learning and dont let the intellectuals bully you into thinking you need ScrumLeanBan in place. Muda… why do they use a Japanese word? Like the cabin, it makes things more mythical. It is what it is.

 

Posted in Agile Theory

Difference in Agile Philosophy

Yeah, it’s rough out there for more senior level professionals. Still, I am not sure if it is the company that my friend is keeping or what, but I have heard about more shady contracts and negotiations in the past 3 months than I can remember in the past 3 years. I see a lot of documents and am a bit of a document geek; the stuff I am seeing lately would be comical in other circumstances.

There is a difference between negation and full disclosure. Obviously. I guess I am old school and expect that you don’t have to say “you have my word” in order for me to assume you are not bring selective in what highly relevant details are revealed. Maybe I am also of a different era – when someone’s word was good as a contract with ramifications should it be broken. I guess I have an Agile philosophy in regard to business. Things change, and that is expected, but you gotta know you are headed the right way.

Agile_development_Related_thing

Again, this is something I’ve learned of through friends. I am waiting for someone at the moment, using my iPhone WordPress app, just venting on their behalf. A bad economy is no excuse for immorality. Now it is true that I have not always been the most moral person in the world. But by word had always been good and I think of Tony Montana… What did he have that he didn’t break for anyone? There is wisdom there. Even rich, we all have to look in the mirror and either see truth or project the image we like. There ate handsomer men than me (so I hear) but I know exactly what u look like and what my friends look like. I do business with friends all the time. It’s great.

In the end, expectations will be met, exceeded, or will fall short of reality. This is important to realize early in any meaningful relationship. Shame on those who use money ad an excuse to bend their word. I denounce you, in full, and curse you on behalf of my friends.

I am personally in a good spot professionally. Today, at least. Things change fast.

You cannot take much for granted these days. What to trust? I only truly trust people and have seen documentation twisted in so many ways that the very idea of it becomes amorphous. Words are, however detailed, ambiguous. This is obviously one issue with BUF requirements in software.

 

 

Posted in Agile Theory

Agile Development, How you know it?

Agile Development is subject to all kinds of theories, including my own (which is really a mishmash of what other people have said and what other people have did – I cannot pretend to have walked down the mountain with stone tablets dictating the Commandments of Building Software and I think the Agile Manifesto – the first page at least – is common sense).

Yes, a lot of this stuff is simple but taking the simple and fine tuning it for a specific environment takes discipline and skill. The traditional project manager blankets a methodology over a project and tucks it in here, loosens it there. They are nervous right now, except in large organizations where silos hold the place up (and those same places will be overtaken in my opinion by leaner, more Agile, more realistic and “human” organizations).

Agile_development_Related_thing

I am already displaying my prejudices. It may be important to note that I am going to write this with all prejudices towards Agility aside, to the largest extent that it is possible to not have an opinion. I will try to say what is my opinion and what is not only my opinion but what is established as a kind of “industry fact”.

Read more here:

Agile, in my mind, is undergoing a bit of a transformation at least in part to Mark Kennaley’s book: SDLC 3.0 Beyond a Tacit Understanding of Agile. I cannot recommend the book until it is released with legible figures and diagrams, but Mark is working on that and we have discussed that. It turns out that the “Waterfall” approach is an erroneous interpretation of a paper from the 70’s.

At least, I will try to not assume one or the other before going down a mental path. As a side note, mostly for Scott Ambler, I do not think that calling someone a Certified Scrum Master implies super powers any more than calling them a Scout Master or Master of Ceremonies does. People are not silly enough to accept things without asking questions, although I have had HR approach me saying they want a CSM with 10 years of SharePoint 2007 experience. HR is a different animal.

We want to be in the middle somewhere but above all else, I believe we (as Clients) want to be the place where the information is and the center of collaboration. The Client organization, if possible, wants to be the “Single Point of Truth” for both documentation and process control. That is knowledge that will be invaluable at some point and it will prevent obfuscation. If a vendor already has something like Bugzilla mastered, you want a login. Do not force change where it will not be helpful, please.

The funny software developers call bugs “features” and I guess after 20 years that is still funny. I prefer separating bugs from issues at least in category buckets myself because then the difference between them becomes more obvious and they are handled differently. If math is being executed and addition is inaccurate, we have a bug/issue but if we are not sure if interfacing with an overseas payment processor is possible without their being PCI audited, that is an issue. An issue I actually encountered not too long ago: a development shop wanted to build a RoR font end on top of Ektron. This was one of those delicate issues that was tracked offline.

As with most things, our objective should be to prevent the disease instead of band-aiding the symptoms. To do that, you also need visibility into the overall project health. You do not need granular detail, but if you know that we have 100 units of stuff to fix last week and this week we have 140, things are not getting better.

This concept of assigning points to features can be applied to bugs as well. It is all is the estimate and difficulty level. You wind up getting a very visible “velocity” over time where you can see time on the X axis and total open points of the Y axis… you want that line to wind up at zero by a date you have in mind or, more realistically, let it tell you when you will hit zero and adjust the feature/bug (product backlog) accordingly. A tell-tale sign that your vendor is not as familiar with bug tracking or issue tracking is, in my opinion, if their unique identifier (ID) changes or if both entities are tracked in the same manner. The idea of velocity and the multiplicity of velocity is staggering. It does not simply apply to Scrum burndown charts.

 

What is its Business Impact?

From low to high and “showstopper” with numeric values attached to the single decimal point. I maintain that with every bug there is associated Business Value, Difficulty, and User Value. These things are not obvious to the tester but they are to the Product Owner. They combine, via simple math, to give a final value. The “showstopper” assignation is there to really propel the bug’s value into the stratosphere. If low is 1 and high is 3, showstopper is 100. How severely will this impact the business if it is not resolved by go-live?

business-impacts

 

What is it’s User Impact? Like Business Impact in calculation, but answers the question: is this just annoying, or does it require a disturbingly complex UX?

How hard will it be to fix? This is often a tie-breaker between bugs when creating the next iteration of work and is also potentially an indicator of weaknesses in the team.  I like it when these are estimates or are story points.

Status:Unassigned, assigned, UAT, accepted. You can add or remove as you choose but I like this foundation. When in UAT, it is waiting for Client approval. These should be no bugs that depend on other bugs if possible, and if a bug can be broken into separate bugs, they should be. Open is vague and not required. If it is assigned to someone or a group, it is not closed.

It makes sense to run through bug priorities as time allows to be sure that their values have not changed. If functionality has been cut out, those bugs will have less Impact. However, one bug does not lose value simply because 8 other high value bugs have been found. New functionality should *not* be added until a development team that is constrained by resources can catch up. It is better to have 50 percent of the features complete with 50 percent buggy that 100 percent of the features unusable. Maybe the System cannot be used with 50 percent functionality, but you have value in your pocket there and have paid for something that can be moved to another vendor, another release, or re-purposed or sold. Always try to retain rights to and a copy of your source code in your contracts involving custom development. Otherwise, with a new vendor, you are better off starting over. Earned Value will be nil. This is only one of many reasons why “percent complete” is a false indication of anything. Others include that the task/bug changes, has facets revealed that were hidden before, and are as apt to change as anything else.

When a bug is introduced, anyone can introduce it. The default owner should be the Project Manger / Coordinator / Technical Liaison, or whatever the role is called. The Product Owner may also do this but are better off using their time in other ways. This is where the traditional Project Manager can breathe a little sigh of relief amongst all the talk that Agile and Scrum are making the PM role irrelevant.

The Project Manager, in a technical setting, should have knowledge of technical systems. They can and should work with the Product Manager to tune value and assign bugs or issues after they are introduced into the System. However, the project manager does not assign to a person. People come and go. They get hit by the proverbial bus. Bugs and tasks are assigned to groups, such as “Development” and then divvied up within that group (hopefully using the same tool) so people are mapped to bugs and there is a face at the standup who will be speaking about it.

Also, much as we get a sense of project velocity, we can get personal velocity. I say that and bite my lip, because there is always the “X factor” leaning on everything we do and using pure metrics to ascertain the value of a person is bad, bad, bad, and horrible. This, again, is where the classic project manager could be knowledgeable. You may notice that I am mixing and matching Scrum terms, Agile terms, and more common terms to describe roles.

That is not without reason. There is a basic methodology-independent rationale here: keep track of things, limit dependencies, keep visibility and communication high, and stay flexible. Look at what work there is to do and compare it to your deadline instead of trying to shove 10 pounds of tasks into a 5 pound box.

How is bug tracking system working

  1. Reported By
  2. Date Reported
  3. Owner (defaulting to the PM/Technical Liaison)
  4. Summary/Description
  5. Acceptance Criteria
  6. Supporting Documentation (documents with screenshots, etc)
  7. Site/s
  8. Business Value (1-10 or 100 with one decimal place)
  9. User Value (1-10 or 100 with one decimal place)
  10. Technical Difficulty (high value means it is more difficult and risky… a risk mitigation worksheet is already available and complimentary).
  11. Status
  12. Date of Status Change (so if something lies around for a week, for instance, it is obvious).