function method97 ($num) {
$a = $num * 100 / 97;
$k = 98 - round (97*($a-floor($a)));
if (strlen($k) == 1){$k="0".$k;}
return ($k);
}

First step: Creating keystore

You can create your keystore file using keytool.exe (or keytool.sh on linux) which is part of your Java SDK. You can find it in <JAVA_HOME>/bin folder. If you have this folder in your PATH environment variable, you can use it from any position on folder structure. Syntax example is:

keytool -genkey -v -keystore <keystore_file_name> -alias <alias_name> -keyalg <algorithm> -keysize <size_of_key> -validity <cert_validity_in_days>

For instance:

keytool -genkey -v -keystore marko.keystore -alias MarkoAndroidAlias -keyalg RSA -keysize 2048 -validity 10000

Notice here that you have to set validity more than 25 years (~9130 days), so 10000 will do.

Second step: Signing your application

For this purpose you can use jarsigner.exe which is positioned in you <JAVA_HOME>/bin folder too. Here is the syntax example:

jarsigner -verbose -keystore <keystore_file_name> <application_name>.apk <alias_name>

Notice that keystore_file_name and alias_name must match previous command. For example:

jarsigner -verbose -keystore marko.keystore MarkoApp.apk MarkoAndroidAlias


Third step: Aligning the signed file

For better reading file performance purposes it is good to do alignment. For this you can use zipalign tool in <ANDROID_HOME>/tool folder. Here is the example of syntax:

zipalign -v 4 app-unaligned.apk app-aligned.apk

Remember to use “4″ always for 4-byte alignment, which is optimal for Android OS.

Now, your Android application is signed and aligned.

Important notice: Keep your keystore file safe, because you have to use it and only the same keystore for signing this application on Android Market.

First, I downloaded axis-1.4 and put it in some folder (C:\temp\axis). Then in command line (windows) I did:

CLASSPATH=C:\temp\axis\axis-1_4\lib\axis-ant.jar;C:\temp\axis\axis-1_4\lib\axis.jar;C:\temp\axis\axis-1_4\lib\commons-discovery-0.2.jar;C:\temp\axis\axis-1_4\lib\commons-logging-1.0.4.jar;C:\temp\axis\axis-1_4\lib\jaxrpc.jar;C:\temp\axis\axis-1_4\lib\log4j-1.2.8.jar;C:\temp\axis\axis-1_4\lib\saaj.jar;C:\temp\axis\axis-1_4\lib\wsdl4j-1.5.1.jar

then I went to my WSDL and xsd folder. After this:

java org.apache.axis.wsdl.WSDL2Java -a -v filename.wsdl

Since I had several wsdl files, I had to repeat command above. Now I had my structure fully created. After this I could easily copy complete folder to my Eclipse project.

Not to forget: if you have xsd files with types definitions, just put them in the same folder with WSDLs.

Years ago, in the dawn of my Scrum voyage, I was asked by my colleague from the sales department to estimate a project. The situation was kind of complicated; I would say kind of weird from the beginning.

The project was a web application, which was supposed to service about a thousand simultaneous users. The client was in another country, so we communicated only over Skype and e-mail. I got this estimation task in late January and was told that the application should be finished in a beta version by February 1, and a final version should be released on March 1. “Tight schedule, very tight,” I thought. And we didn’t even have the team assembled because our developers were on other projects and pretty busy. So, we needed to gather the team, to find developers, and to finish the project (beta) in two weeks. “Pretty challenging,” I told my colleague. He already had some contacts with a recruiter and told me that finding a “few programmers” wasn’t a problem. “Ok, let’s have an online meeting with the company owner,” I suggested. So, we had the meeting. Apparently, they had started this project six months prior with just one developer. I thought this was interesting. A few days prior to our meeting, the developer told the client (“Jack”) that he had to leave the project for personal reasons. “Even more interesting,” I thought and smiled to Gary (my colleague from sales department). Now, the Client had promised the stakeholders that they would deliver the beta version in two weeks and the final version after a month. If they couldn’t deliver, they would have to refund money with penalties. So, Jack was ready to pay big money to have this project finished on time, and Gary saw a nice opportunity for our company. I saw an opportunity to show the power of Scrum, but I was a little worried that the team didn’t exist at that moment.

“Hey Jack,” I asked, “do you have an idea what has been done and what is supposed to be done by our team?”

“No problem, I have an online demo,” answered Jack, “and I reviewed the application thoroughly with our developer. He told me that application was 85% finished.”

“This is great!” I said, “Why don’t you release this version with all the completed functionality, and we can work on the remaining 15%! This way you and your partners would have a faster return on investment.”

“No, no, you don’t understand,” Jack told us, “We have all the functionality developed. The developer told me that each feature is 85% finished.”

I was speechless. “Ok,” I said, “so, you have a definition of done with seven items, and for each functionality, six items are finished and one remains to be finished, correct?”

“Errr…sorry, I didn’t hear you well,” answered Jack. “You were talking about some „definition of done”, right? What is the definition of done?” At this moment I was almost terrified. He didn’t have any idea what was done on the project.

I tried to be calm. “Ok, but how do you know that the project and each functionality was 85% done?”

“Well, the developer told me so,” he said.

The good thing was that he had full confidence in this guy. I was pretty skeptical. I was interested to see what was really done on the project.

“Ok,” I told Jack, “would you send to us some online demo info and a list of requirements, please? We will analyze this and get back to you with our estimates.”

“Great,” Jack said. I suppose that he was thinking we were already on the project. The work day was almost over and Gary and I decided to work until we had some estimates for Jack. So, we worked hard for the next four hours. I did estimates for programming work and Gary was testing the “almost finished” functionalities. I did optimistic (but still realistic) estimations. Gary was working on the functionalities list, comparing it with the online demo.

After the job was finished we had a conversation. Gary showed the functionalities to me, one by one. After each one, we were more and more worried. At the end we did a draft estimate of the developers’ work needed for finishing the project. The best-case scenario was that, with a good team of experienced (read: more expensive) developers, the beta version could be deployed on March 15 and the production could start on May 1. This was an optimistic estimate. Jack’s (or developer’s) “85%” wasn’t 85% – but actually between 15% and 50%.

I told Gary, “Let’s drop all of it. We should do everything from scratch and do it right. Let’s suggest this to Jack.” And by “right,” I meant “in Scrum way.” I knew that we couldn’t do a good job by continuing to work on the existing code. It was pretty messy; no tests, no code documentation, no basic documentation at all. And I was sure that we couldn’t commit to finish a beta version in two weeks. Not to mention that we didn’t have the team yet.

After four hours of working on the estimate and analyzing the project, we got back to Jack. I suggested to him to start from the beginning right away and told him that he needed to speak with the stakeholders. He didn’t like what he heard. “Hey, we need to go beta in two weeks. I don’t care how much it will cost. Add ten developers if needed!” he was upset; I could hear it in his voice.

I didn’t know about Brook’s law at that time, but I had some experience with adding more developers to a project, and I did explain to him that it would probably not solve the problem.

I suggested that the only way to make the project healthy and avoid failure was to get real, to present the stakeholders with the real situation, to accept responsibility, and to deal with it. We would help this project to succeed at a lesser cost than what they already had spent, and produce it three times quicker than they had planned at the beginning.

“No,” he said, “my project is 85% done. I will find some other team that will finish it in time. Thank you for your time.”

I was amazed. He was hypnotized by the evil magic of “85% done.” I knew this project was doomed. And very soon, unfortunately, we could see that I was right. The website has never seen daylight.

Years after this experience, I faced the “evil magic of 85%” several times. We didn’t get this job, but I gained great experience from it. Whenever I heard that I should join/save a project that was in trouble and “85% done,” I knew that something was wrong. Some of those projects I finished successfully and saved them. Some of them failed. But almost every time when failure occurred, people (top managers) were seemingly hypnotized, repeating “we’re almost done!” I like Scrum, among other things, because it emphasizes a clear definition of done. A story is done or not done. There is no such thing as “almost done.” There either is or isn’t business value, no matter what tasks developers have finished. There is no such thing as “85% done.” And once again, I don’t mean 85% of all user stories. I mean 85% of each user story. By Scrum criteria, this means 0% of project. With 85% of all user stories “done done,” I would probably go live with my application and would be very happy about that.

I was thinking about this evil magic of “85% done.” Why is it so powerful? Here are some of possible reasons.

First, it makes us think we’re almost there. “Hey, just one small effort and we’re there.” This number gives us a comforting feeling that we can relax, because the job is almost done.

Second, this number is ideal, because it’s not too big – so in case someone wants to check the work, the missing 15% can be always be blamed on something not working – even if it is at the very beginning. This number is not small either, preventing someone from saying you are far from finishing the job. This evil number is perfectly chosen for its evil purpose – to keep us from establishing a definition of done and really finishing the story/project.

Third, this number is not quickly verifiable. You can say it and nobody could check if it is true, without getting deep in the code.

All in all, don’t trust a manager or developer who claims that 85% of a story is done. You can run away from these situations or you can use Scrum and a definition of done as powerful tools for fighting this evil and save the world (of the project at least).

And to all of you Scrum guys – don’t measure progress within the story. A story is done, or it is not done. Please, make a definition of done suitable for your project with your Scrum team and stick to it. Make your user stories small and doable in a Sprint. A user story is a measurement for the business value of your software. So, deliver done user stories, deliver complete business value, and, of course, don’t forget; beware of the evil “85% done.”

By: Marko Majkic, CSM CSP – as published on ScrumAlliance site

When I was first introduced to Scrum, I thought “What an easy and beautiful way to be efficient!” After years of doing Scrum, I found that it‟s not that easy. It was easy to learn. And, as many times before, “easy come, easy go” was true. It was very easy forget easily learned facts of Scrum. I‟ll tell you about some of the traps me and my friends experienced during Scrum implementation. Solving these was more or less successful, but if you recognize at least one of them in your environment, which you weren‟t aware of before, my article was a success. I will tell you five real stories about people who were on the edge of Scrum and how they succeeded in avoiding Scrum traps. My Scrum heroes’ names have been changed to protect their identity. Let’s begin.

Proxying Product Owner

“Beware of the ScrumMaster who thinks that he can permanently assume the Product Owner role,” I would say. I’ve heard a similar saying before, “A good ScrumMaster can handle two teams and a great one can handle only one.” If you try to do the ScrumMaster and Product Owner role at the same time, you’re doomed. You won’t be able to perform both roles correctly – that‟s certain.

One day, Scott was told at the very end of a Sprint that the Product Owner on the project had to move to another project that had stalled. He was told to act as Product Owner proxy for some time. Scott and the team were in a highly dynamic and quickly changing business, and it was a pretty tough period for the team. The first issue Scott was facing was time. The Sprint was one week long, and he did partially succeed in resolving impediments and barely succeeded in preparing acceptable user stories during the first Sprint. The second Sprint was a total disaster. Impediments started to pile up, and Scott didn’t succeed in preparing acceptable user stories. The Product Backlog was filled with a few essays, without good, smaller user stories. And Scott was a pretty good problem solver. He would have certainly been a great Product Owner, if he was focused only on this role. Simply, Scott didn’t have enough time to do both roles well for the team. Another issue Scott experienced was context switching, but maybe this is the wrong term. A better term is perspective switching. That was very stressful. At one moment Scott was trying to solve impediments and at another trying to figure out which story would return the investment in the best way. How did Scott deal with this? He didn’t. He told the stakeholders to delegate a new Product Owner. Even a non-experienced Product Owner is a better solution than a ScrumMaster acting as Product Owner proxy. Luckily, Scott’s Product Owner returned and he was able to keep Scrum on the track.

ScrumMaster as a Team lead

Claire had a pretty strong technical background on system administration, networks, and Java software architecture/development. Top management considered this to be a great asset to the team she was supposed to serve as a ScrumMaster. Because top management had a foggy understanding of Scrum, Claire was considered to be a “Team Leader.” Claire was the most experienced programmer in this team, but didn’t even have the role of developer. The other team members were really great developers and quick learners, but new to Scrum. They didn’t quite understand the nature of her engagement in the project, even though she had tried to be pretty clear about her role. They knew Claire before this project and had respect for her as a developer. I suppose they expected her to deal with technical issues using her remarkable experience. This asset started to become a great burden for the team and for Claire personally. She knew that if she got deep into coding she wouldn’t be able to act as a good ScrumMaster. The first Sprint Planning Meeting started, but when technical debt was discussed, everybody looked at her, expecting her valuable opinion. She remembered something that she heard once from a more experienced Scrum Coach. She asked the team to excuse her for some time and to continue the technical discussion without her. They were surprised, but after she left, they did continue. After some time she returned and they barely noticed her. She was satisfied with the result. When the meeting was finished, she asked the team if everything was ok and how they decided to address technical solutions. Everything was fine and the team was satisfied because they handled everything themselves. She suggested that they would feel better if they made decisions on technical stuff, and that they were very good developers. “Of course,” she said, “I’ll give suggestions if needed, but I’m not supposed to make decisions. The team has the power to decide. My job is to serve the team and to be sure that the project and work are running smoothly.” Claire made an “impediment list” sticky note on the wall and asked the team to give her tasks whenever they wanted, no matter what issues they might have. Then they really understood her role on the project.

Support Departments Don’t Use Scrum

Robert was a Scrum Coach for a software department that developed in-house projects. They had used Scrum for almost a year, and were doing a great job. When Robert came to the company, the department was pretty messed up, but in a few months everything fell into place and the teams became hyper productive. This was recognized by top management, teams were regularly awarded, and everything was fine. But Robert was a little worried. At first, he was focused on the teams, and wasn’t able to see the whole picture. Using Scrum, real issues were surfacing, but he was focused on the issues he had influence over, and the team was solving them. So, when impediments inside the department were minor, other impediments became visible. The first sign of trouble was that the Product Backlog was pretty empty. He talked with Product Owners and discovered that they couldn’t get enough information to create acceptable user stories. “Why?” he asked. Simply put, nobody from other departments had the time to define what they needed, and when they needed some functionality, they needed it immediately. From his perspective, communication with other departments was an impediment, but he felt responsible to initiate the solution. Now, because teams were pretty self-organized and doing well, it was time to spread Scrum to the other departments. First he talked to top management about the situation in other departments and presented the idea about introducing Scrum. They hadn‟t originally considered it, but were pretty satisfied with the re-organization of the software department, so they agreed. Robert explained that he didn’t want to make this transition top-down, but would try with volunteers. He invited heads of each department to a working breakfast and explained Scrum, presenting potential benefits for the department using its principles. He asked them to bring a few team members to the next three meetings about Scrum. They were pretty shocked when he introduced some of the Scrum games, expecting a PowerPoint presentation. “Hey, you didn’t even bring your laptop,” they said. “I don’t need it,” Robert replied. After playing two games, he conducted a practice retrospective meeting, allowing the teams to reach their own conclusions. Then he helped them to make parallels with real situations that they were dealing with. It was quite refreshing and revealing for most of them. Then, he explained that Scrum was not a silver bullet, but a tool that could help them to understand the impediments and to enable them to work better. He asked them to consider it and to let him know if they would like to try Scrum in their environment. The next day, the chief of the technical support department contacted Robert, claiming that his team was overwhelmed and eager to try Scrum. “Great!” Robert said. “Let’s start preparations for our first Sprint.”

Disputed Definition of Done

Ulrich was a pretty experienced Scrum Practitioner. He knew that coaching a new team was going to be tough. They were all experienced programmers, but new to Scrum. Initially, coaching was tough, with much resistance and conflicts; a bumpy road that was now almost behind him. Eventually, things were much smoother because he knew the team’s velocity and the team knew their velocity, which was much more important. Velocity was regarding to “DONE DONE” user stories. He remembered the issue the team had with this, theirdefinition of done (DoD). As he explained at the very beginning, the team and the Product Owner had to reach an agreement on this. One of the guys came up with a DoD proposition, and the team and the Product Owner were ok with it. One of the items in this list was “unit test coverage of 80%.” After the first few stories were “done,” he asked the Product Owner to test the items from these stories. With the tool they had, it was easy to see a unit test coverage of 23%. Ulrich asked the Product Owner what he thought about that. He answered that he wasn’t satisfied with that the result. “Why?” asked Ulrich. “Because these stories are not done,” replied the Product Owner. “Do you need a unit test coverage of 80%?” asked Ulrich. “No, I don’t know why they chose these figures, but if the team defined these, I expect them to meet these criteria,” answered the Product Owner. And he was right. The Sprint ended the next day, and during the Sprint Retrospective, Ulrich announced that the Sprint had failed, which provoked a very emotional response from the team members. He explained the reason and showed them real figures on test coverage. “But why is this important? We did all the necessary tests. We didn’t want to waste time unit testing trivial methods, such as getters and setters, and we didn’t want to test something covered in integration testing,” screamed the guy who purposed the DoD criteria. “Yes, you are completely right, but you promised something about unit testing and this was not accomplished. Could you tell me how you determined the proposed DoD?” Ulrich asked. “Well, I didn’t know what criteria to propose, so I copied some from a Scrum blog, which looked great at this time.” “Ok, guys,” Ulrich said, “this is my failure as Scrum Coach as well and it’s my fault that you didn’t understand the meaning and importance of DoD. DoD is different from team to team and project to project. This is not a general standard that should be implemented in all situations. And Scrum is not a standard that can be implemented the same way in all situations. Those are tools, which help you make better software, but you need to involve your intelligence, energy and creativity to make it happen. Ok, let’s do the job. Let’s create a DoD acceptable to us and our Product Owner. You are experienced developers and you know everything about good programming practices. You’ve seen one of many possible DoD’s. Let‟s make new a DoD we can commit to.”

Estimations in hours

Marianne was inexperienced, but passionate about Scrum. She started her first Scrum project with the team and was thrilled, anticipating her first ScrumMaster job. The team knew about Scrum and was interested in trying it. Before the first Sprint Planning Meeting, the Scrum team agreed on some conventions and one of them was estimating user stories and tasks in hours. This was the natural choice for the team and Marianne agreed with that. Estimating in user story points was awkward to the team, since they couldn’t figure out how to correlate this to some real measurement unit. So they started their Sprint meeting and started estimating. They estimated all user stories and chose ones they could commit to finish until the end of Sprint. Then, the Product Owner stood up and spoke. “Well, guys, you just committed to finish user stories worth 230 hours and you have 400 working hours in your Sprint. Even if we add 30 hours for the meetings during the Sprint, still there’s 140 hours in the Sprint you should commit to. Is my math correct?” “Yes, you’re right,” said the senior developer, “but a working hour cannot be equal to a development hour. We have to have time to think about the story, business process, architecture etc. So, coding functionality is not the only job we’re working on. Development is the intellectual process, not an exact, simple operation. We really didn’t underestimate, in my opinion, and we didn’t want to „steal‟ some time. I just feel that we cannot commit to more than we already did.” “Ok guys,” continued the Product Owner, “I believe you were honest with the estimations and I think that this is a fine velocity if you meet those commitments with your definition of done. I just can’t figure out this difference and it would be difficult for me to explain this to the stakeholders.” It was good timing for Marianne to do some facilitation work. “The way I see it,” she said, “we have a problem with the measurement unit. The Product Owner is satisfied with the features to be developed in this Sprint, but somehow user stories measured in hours don’t provide the real information, correct? Furthermore, this difference in time is causing confusion. If developer hours cannot linearly correlate with real time, why don’t we say points, not hours? After a few Sprints, we will be better in our estimations in these points, correct? And there will be no confusion with working hours and time. After a few Sprints, we will know our velocity in these points and will have more experience in estimating work. Stakeholders will get their graphics in these points and will be able to monitor progress daily. What do you think?” The Product Owner was delighted with this idea, knowing that he’d be able to show diagrams to the stakeholders in real time, and the team was relieved from the pressure they felt after Product Owner’s speech. Marianne scored her first small victory helping her team to overcome its first impediment and potential conflict. After a few Sprints, they got used to estimations in user story points, so it came naturally to them.

I hope that you enjoyed these real Scrum stories and that you can recognize some of the situations in your everyday Scrum practice. Please comment on them and comment on how you would deal with these situations.

#!/bin/bash
# Bamboo startup script
# chkconfig: 345 90 90
# description: Atlassian Bamboo

BAMBOO_USER=bamboo
BAMBOO_HOME=/usr/local/bin/bamboo
start() {
echo “Starting BAmboo: “
if [ "x$USER" != "x$BAMBOO_USER" ]; then
su – $BAMBOO_USER -c “$BAMBOO_HOME/bamboo.sh start”
else
$BAMBOO_HOME/bamboo.sh start
fi
echo “done.”
}
stop() {
echo “Shutting down Fisheye: “
if [ "x$USER" != "x$BAMBOO_USER" ]; then
su – $BAMBOO_USER -c “$BAMBOO_HOME/bamboo.sh stop”
else
$BAMBOO_HOME/bamboo.sh stop
fi
echo “done.”
}

case “$1″ in
start)
start
;;
stop)
stop
;;
status)
su – $BAMBOO_USER -c “$BAMBOO_HOME/bamboo.sh status”
;;
reload)
echo -n “Reloading bamboo: “
killproc bamboo -HUP
echo
;;
restart)
stop
sleep 10
start
;;
*)
echo “Usage: $0 {start|stop|restart|reload|status}”
esac

exit 0

ProxyPass /myApp ajp://localhost:8009/myApp/

DNS should hit the server. If the server is aaa.mycompany.com then A record of DNS (aaa A 192.168.32.33 – for example) should exist. Now when you enter http://aaa.mycompany.com/myApp you should get your application. Simple as that.

But this time we should deploy two small applications on the same server with two different urls (at least different A records): bbb.mycompany.com and ccc.mycompany.com. I tried to add virtual host only, but it didn’t work as I expected. I did a lot of googling, but there wasn’t any for-dummies solution. So I had to read a lot of different articles, documentation etc. I hope that this would save you some time doing the same thing. Here is the solution.

First don’t use any global proxy_ajp. Add following in httpd.conf


ServerName bbb.mycompany.com
ProxyPass / ajp://bbb.mycompany.com:8009/
ProxyPassReverse / ajp://localhost:8009/myApp/
ProxyRequests Off
ProxyPreserveHost On
ErrorLog logs/bbb.mycompany.com-error_log
CustomLog logs/bbb.mycompany.com-access_log common


In your $CATALINA_HOME/conf/server.xml add section under localhost section.

Usually, people have prejudices about everything, including Scrum. This is normal and is ok as long as we are aware of these prejudices and we’re ready to deal with them.

Scrum is usually compared to those project processes, methodologies, frameworks we already know about and Scrum is lined up with them, colored with our expectations. People get know about Scrum in a different ways, goggled, were told by a friend, heard about it on a conference or heard as a buzzword. Anyway they come to the Scrum in hordes, there is no person that I heard of who didn’t think “Hey, this is really simple!” and who wasn’t delighted with Scrum’s simplicity. Because of this fact, Scrum is honey pot for the IT community.

Scrum attracts people very EASYly.
Scrum basics are very EASY to learn and understand.
Scrum is EASY to start with.

That’s all about EASY Scrum. All which comes after that is HARD. And, by my opinion, this transition from EASY to HARD state of mind is the biggest issue in failed Scrum implementations. We are not prepared, we are lazy, we don’t want to work hard and we are always looking for easier way to succeed. That’s all human. But humans are intelligent beings. We should inspect and adapt. We should inspect issues which appear. We should adapt to those, new circumstances.

Yes, I understand disappointment of knowing that it’s not everything about sweet Scrum. Bitter taste after first issues start coming, pushing us away from Scrum. When impediments start coming up, all “the dirt” will start coming to the surface, showing ugly face of our project, habits, organization and at last us. Pretty tough choice we have now. Hey Neo, would you take red or blue pill?

Those who choose easier way tend to give up, blaming Scrum for troubles and failure. Hey, we are perfect, convicted to live in this imperfect world. This way of thinking improves our morale, self-esteem, self-confidence for sure. For some time, at least. Those aforementioned are pretty hungry beasts that should be fed often. And they are always hungry making us their slaves.

To break free, we have to be brave, we have to say “ENOUGH.” We have to take another bitter bite, and then another and so on, until only crumbs remain.

Those who stand against those issues, dealing with them, despite this bitter taste have good chance to become great change agents, great ScrumMasters and good ScrumCoaches. Deal with all those challenges and you’ll earn real self-esteem, self-confidence and respect of people you work with. Fighting the impediments and Scrum principles, you are fighting for the good cause.
Those who retreat shouldn’t be criticized, but supported, encouraged and coached. Falling is normal, there’s “gravity” – easier way which bring us down, but stand up and keep to the Scrum principles. It’s quite rewarding at the end. After winning those battles, beating all impediments, you will be able to say proudly: “I’m the ScrumMaster!”.

Doing Scrum usually means that you will conflict people at some point. Conflict is quite stressful and tough thing to happen. Conflicts are impediments in your Scrum implementation and you are the one who is expected to solve them. Yes, tough job. You are the one who is expected to tell the people the truth about ugly reality, which, sometimes, could be painful. Tough job again. And remember, there’s no EASY way to do the job. Don’t try to find workaround, just do the right thing. Sometimes you won’t know what the right thing is, but you’ll feel it, as long as Scrum is with you.

There are people there who didn’t give up the Scrum (at least not completely), don’t use Scrum, but use this buzzword claiming that they are Agile and efficient. Hmmm…nice to be in Scrum and Agile company, just like claiming to drive Ferrari, but you’re not. This would mean that you are successful, being in a good company, high class. But what’s the real value of it. None! At last when you reflect in mirror of Scrum, you’ll see guy driving 30-year old car, worth nothing. Reflecting, you’ll still see non-functional teams, organizations, bad software habits. No real value. This illusion will disappear very soon and your software will still suck. Yes, this was also one EASY way, but wrong as well.

Wake up, there’s no EASY way.

Scrum is EASY to understand and embrace, but be careful, don’t be easy-minded, or you’ll be misled. Don’t blame Scrum for it. Living with Scrum is not easy, but I feel great, because I believe Scrum gives me opportunity to do my job honestly. And after doing Scrum for a few years and coaching Scrum for a year and a half in my company, I can tell you this: It is rewarding. I remember the mess I found there at the begging. And I look at it now. I feel as a parent whose child has become a decent person. “Just look at him!” I can proudly say. And no, it is not the Scrum. I did it. But I’m really grateful to Scrum and to all the people I learnt Scrum from and I taught Scrum. Scrum gave me the tool which I used to help creating beautiful teams, relationships, processes and organization. At last I feel that I improved myself on this path.

And once more: Scrum is easy to learn, but doing it is difficult. Be careful. Don’t expect easy tasks on this path. Don’t expect easy shortcut to victory. Be courageous. Scrum will reward you, helping you on this path. Bringing results, your work will be recognized and you will improve your professional career. You will bring good changes to your teams, processes and the organization. You will change people in a good way. You will improve yourself on this path.

Scrum, thanks for not being EASY! Thanks for improving me on this bumpy road.

I’m coaching (Scrum) people in my company for more than year and a half, but being a Scrum doctor gave me totally another perspective and I enjoyed in it. Actually, I was provoked to think harder, sharper, more global, because my “patient” was pretty experienced in IT, team leading and Scrum too. I hope I did help him. I know that he helped me. I got opportunity to approach his problem from the perspective i didn’t used to, teaching him, I did learn a lot too. This is similar feeling I’m experiencing for years, as karate sensei, teaching my young students.

Speaking with other people there, I discovered that they weren’t comfortable entering the clinic. Reason was simple: name of it. They were kind of ashamed to enter there and admit that they were “ill”. Another reason was relationship “doctor”-”patient” which was kind of “master-slave”, “upper-lower” position. It was pretty irrational and non-scrum by my opinion, but it was real. Should we do something about this? I think yes, making those session more acceptable to the people.

The whole idea of Dialog Room, where among other occasions was Scrum Clinic, was really great, and was the brightest spot of complete Scrum Gathering (SG) in Munich, shining with real scrum spirit. Don’t get me wrong, there were few (I was on three) really great sessions on this theater type setup. But Dialog Room was fully in the Scrum way. My suggestion would be to do it more this way in the future Scrum gatherings/days.

At the end of the second day, spontaneous idea of open space came up, initiated by Deborah and accepted by the most of the SG participants. Thank to this, SG started to look like Scrum Conference and this, third, day saved Scrum Alliance and SG in my eyes. Before that, I was pretty disappointed. I was disappointed in Jeff, talking much about CMMI (what the hell is CMMI?), in Mike Cohn saying no news, both in boring theater type largest ball room atmosphere, without any involvement of the participants, with no passion for Scrum in their eyes, neither the things they were talking about. I was thinking: “SA has a problem. Scrum leading people are not passionate about Scrum any more – is there any future for Scrum? For sure, there’s no value from SG for me by now.” But then, thanks to Deborah, Tobias, Mike Sutton and many other passionate Scrummers, third day return my faith in the Scrum future. Open space (Guerrilla) appeared on stage of SG, and conference started to be fun, involving people in it in wider and more visible way (than great Scrum Clinic and Dialog room before it). It was happening in the main lobby – near the food and coffee, which was maybe crucial for success . Great games we played, started talking to each other more and started collaboration – that was the real Scrum spirit.

I hope that SA board will recognize this Scrum spirit and mention this on SG Munich retrospective meeting. I hope that Jeff and Mike (Cohn) will read this, because I was great fan of them, reading their books and articles. They significantly influenced my Scrum way, and I would like to see them passionate about Scrum as I (and all the Scrum community I suppose) was visualizing them.

I’m looking forward to the next Scrum/Agile event and I hope things will become better for the Scrum community and ScrumAlliance. I’m ready to contribute. I hope that other people from the community are willing to contribute as well and that our help will be accepted.

FORM THE TEAM
Seek the best team members you can based on the projects needs. Size, complexity, technology and the nature of the project will determine the kind of people you’ll need. No matter what, though, you’ll need good people. Obviously, technical skills are important, but just as important is their enthusiasm and willingness to be part of the project.
To fully support the project, the project team will pull from all of these areas,
- Technical
- Quality assurance
- Management
- Operations

Roles will vary, but in general you’ll need people in each of these roles,
- Account executive
- Technical leader
- Developers
- QA engineers
- Graphic designer
- Scrum Master

Other support roles as configuration managers, etc.
In all case, be sure to pick the person best suited for each of these roles. Not only the most skillful, but also the most committed.

KICK-OFF
The Kick-off meeting is the first time that you will fully engage with your client, once all the sales stuff is out of the way and everything has come together. It is important to officially mark the start the project. At this meeting, everybody in the team gets to know each other and discuss everybody’s role.
A typical Kick-off meeting agenda should cover the following,
- Team introduction
- Roles of and contributions from the stakeholders
- Initial risks and issues involved
- Project objectives
- Criteria for successful completion
- Business objectives
- Responsibilities of each member
- Reporting procedures and communication plan
- Key milestones

PROJECT SETUP
It is very important to take time to set up the scaffolding for the project at this stage, before anybody starts coding.

PROCESSES ALIGNMENT
Make sure that everybody’s expectations are clearly lined up. Success is not all just about coding, it also involves these, among others,
- Code review actors and strategy
- Version control repository (SVN recommended)
- Continuous integration environment
- Unit testing tools and environment
- QA strategy (QA automation is a must)
Make sure all involved understand that these are required, not optional tasks and activities required for the success of the project (e.g., No, you are not done until the unit tests are written and the code passes).

DEVELOPMENT ENVIRONMENT
You also need to put some infrastructure in place right from the start, including,
Local environments with required tools (e.g., IDE, Firebug, SVN, MSSQL, third party components, etc.)
Testing, production and database servers

METRICS GATHERING
For the purpose of improving your performance over time, it is important to collect metrics (e.g., defects density, estimated v.s. real effort, etc). Put these tools in place so everybody knows how to use them, the time it takes to integrate them, etc.

START YOUR ENGINES…
To set it in the right direction, it is very important to do these activities at the start of the project,
Sprint planning, this is a commitment driven planning session where the team clarify requirements, make estimates and decide what features will be completed during the Sprint.
To have a product backlog to contain feature estimates and assumptions.
Define schedule for, and attend daily meetings.
Build functionality within the Sprint, including architecture, design, code, unit testing, and code reviews.
Release to testing through continuous integration.
Debug functionality upon QA feedback.
Release to production after every iteration. Your QA team plays an important role here.

MONITOR PROGRESS
This will be based on the methodology you use (i.e., hopefully, Agile),
- Ensure your team is delivering quality and on a timely basis.
- The team is using best practices (e.g., continuous integration, unit testing, agile, etc.)
- The team is meeting client expectations and delivering value right from the start.
- Remove barriers, manage risks, improve communication every day (communication, like money, there’s never enough).
- Everybody in the team is committed and responsibilities are fulfilled.
Good luck!
(Borrowed from some googled site – cannot find it again for reference)